From installing transactions to owning the continuing systems account

Mandate

Preserve business meaning and ownership across subsidiary systems and group reporting

Outcomes

• Six of eight disputed reporting measures made comparable; two retained separately labelled
• Thirty of 186 reviewed software entitlements retired; twelve reassessed items retained with owners
• Fourteen of seventeen unowned retention categories assigned approved custodians; three remained restricted

Decisions in context

The CIO appointment broadened my responsibility from a defined separation programme to the continuing quality of the company's systems account. I lead twenty-eight colleagues through four managers, with delegated IT expense and approved programme capital rather than the company's full financial authority. Reporting definitions, software ownership and retained records now require decisions that remain useful after a project team has moved on. I work with finance, operations, legal and technical owners to make those decisions executable and visible. The role does not give me authority to release products or decide accounting treatment. I have learned to retain a qualified result when the underlying business difference remains unresolved. Two separately labelled measures or three restricted record categories may be the most accurate outcome. My responsibility is to explain that outcome clearly, fund the work behind it and avoid converting a tidy systems presentation into a claim the business cannot support.

Reason for the move

Current appointment; exploring one compatible non-executive contribution without leaving executive responsibilities

Mandate

Establish the subsidiary's systems responsibility while preserving usable business history

Outcomes

• Defined receiving-business acceptance separately from technical transfer
• Resolved thirty-one of thirty-seven provenance exceptions in a 420-record review
• Kept six records restricted after a six-week transfer delay and ₹64 lakh programme

Decisions in context

I joined to help the subsidiary take responsibility for its own business systems without assuming that a copied history was an accepted history. The director title described my employment remit and carried no statutory board appointment. Twenty-one colleagues worked through three managers, with a distinct annual expense and approved capital allocation. The most useful lesson came from the product-history transfer: thirty-seven of 420 reviewed records needed provenance work, and six remained restricted after the funded intervention. I supported a six-week delay rather than let the milestone conceal those limits. This required an uncomfortable conversation about project completion, because the receiving company still needed to operate while support arrangements continued. I learned to make the recipient's obligation explicit and to preserve the exception status beyond the handover meeting. The move to CIO followed the need for that discipline across the ongoing organisation, not a claim that every separation question had vanished.

Reason for the move

Promoted to CIO as responsibility shifted from separation work to continuing enterprise systems leadership

Mandate

Coordinate plant and finance applications without obscuring local business definitions

Outcomes

• Established business owners for cross-plant reporting definitions
• Separated approved programme capital from recurring application expense
• Built a review route for differences that could not be resolved by a common screen

Decisions in context

The promotion put me between plant and finance applications that had developed different meanings for apparently familiar terms. Fourteen colleagues and three leads supported a company of 410 employees at the point of promotion. I reported to the CFO, but did not inherit accounting policy authority. My task was to make the applications reflect decisions made by the responsible functions and to identify where those decisions were still missing. A common screen could simplify training while concealing an important local distinction. I learned to ask whether the proposed standard described the same transaction before arguing about configuration. The annual systems expense and approved capital allocation created a clearer responsibility for the cost of that work. By the time I moved, I wanted to apply the same discipline to a larger boundary: the point at which a business receives systems and history from another organisational owner.

Reason for the move

Accepted a subsidiary separation remit to work on business ownership across an organisational boundary

Mandate

Support the applications used by the manufacturing business through changing products and staff

Outcomes

• Linked application changes to named business decision owners
• Kept support responsibility active after installation acceptance
• Completed a part-time enterprise systems diploma in November 2008

Decisions in context

Moving from a software supplier into a manufacturing company changed what completion meant to me. Six colleagues supported applications that would still need to make sense at the next month end and after the next product change. I could not leave with an accepted installation and assume the business would resolve the remaining interpretation. My annual expense remit was seventy-eight lakh rupees; major capital decisions stayed with management. I began recording who owned a definition and who could approve a change, because a help request often contained a business decision that IT could not make alone. Part-time study at Qervashi Systems Institute, completed in November 2008, gave me a broader language for that work without interrupting employment. The subsequent promotion recognised the need to coordinate these questions across more than one local application and to connect the support account with the company's expanding reporting needs.

Reason for the move

Promoted into enterprise systems leadership as the company expanded its cross-plant remit

Mandate

Configure and explain factory transactions with the people who would use them

Outcomes

• Documented how users interpreted transaction fields after installation
• Brought unresolved business definitions to the delivery manager
• Learned the difference between successful processing and an intelligible operating record

Decisions in context

My first appointment followed the engineering degree completed in May 1996. I joined in July and worked in an eight-person implementation group, with no staff or budget authority. The practical education came from watching a transaction pass through more than one user's hands. A field that seemed obvious during configuration could be interpreted differently by a storekeeper and a finance colleague. I could fix an error in the application, but I could not decide which interpretation the business should adopt without the appropriate owner. I learned to bring that distinction back to the delivery manager rather than quietly choose whichever answer made the installation easier to finish. Customer acceptance was an important milestone, yet it did not show what happened after the team left. That unanswered part of the story drew me toward an internal applications role where I would remain accountable for the next cycle of use.

Reason for the move

Joined a manufacturer to take continuing responsibility for applications after implementation