There is a lot of discussion about deploying AI across the enterprise. Most of it starts with the model, the platform or the tool. I start somewhere else: the work.
There is a lot of discussion about deploying AI across the enterprise. Most of it starts with the model, the platform or the tool. I start somewhere else: the work.
What decision are we trying to improve? What information does a person need at that moment? What gets in the way today? And what should the technology do when the situation does not fit the standard process? Those questions matter whether the employee is working at a desk, supporting a customer, writing software or managing a shift.
The work is different across those environments, but the technology challenge is connected. AI creates value when it is grounded in the context of the work and built into the workflow. It does not create value simply because it has been deployed.
That distinction is important for CIOs. At UKG, our own employees are primarily desk-based. My responsibility is not to run frontline operations. But we build technology for organizations whose work includes both corporate and frontline employees, so we have to understand both environments. The CIO’s role is to create the architecture, standards and operating model that allow AI to be useful across them.
The first question should not be, “Where can we add AI?” It should be, “Where would better information or faster execution change the outcome?”
For a desk-based team, that might mean reducing the time required to find the answer to a customer question, helping an engineer understand a complex codebase or giving a finance leader a clearer view of a business trend. For a frontline manager, it might mean identifying a staffing risk before a shift begins or helping resolve an exception without moving between several systems.
In context
- Topic: Estrategia y Gobierno de TI — Decisiones de portafolio, costo total, gobierno y marcos de referencia.
- Source: CIO
- Published: 14/10/2026
Continue reading at the original source →
Excerpt published automatically by the site radar. The full text belongs to its publisher and is linked above.
Why it matters
IT governance rarely fails for lack of technology. It fails for lack of clarity about who decides what. A story like this one is usually the visible symptom of an operating model that no longer fits the size of the organisation, and those models get changed before the pressure arrives, not after.
I read it looking for coordination cost. Every technology decision splits work across areas that do not report to each other, and that is where the return leaks out. If nobody defined who resolves it when two areas disagree, the project already has its grounding date set.
What usually goes wrong
What usually goes wrong is the part never discussed with the areas that will carry the work. It gets decided at the top, communicated downward, and the resistance shows up not as opposition but as slowness. Nobody says no; everything simply takes twice as long and nobody can explain why.
What to watch
- Who ends up owning the decision, and with what budget of their own rather than borrowed.
- Whether business metrics appear or only delivery metrics — cost per transaction beats percentage complete.
- The real calendar of contracts and renewals: that is where you see whether the move was strategic or was an expiry date.
How I read this entry
If this landed on my desk, the first thing I would ask for is not a plan. It is an honest inventory of what is already running and what it costs to keep it alive. It almost always turns out that the budget for the new thing comes from switching off something old that nobody wants to name, and that conversation decides whether the project lives.
This entry is an excerpt from the original source, selected by the site radar. The commentary above is the site's own and does not belong to the cited publisher.
Comments
No comments yet. Yours can be the first.
Living through this in your own team?
Open the chat and tell me how you're handling it. I'm interested in comparing notes.