Digital transformation is a change in how an organisation works, not just the implementation of a system: it covers processes, people, organisational culture and measures of effect. An implementation ends with acceptance, but the change only begins then. The new system works technically, yet people still work the old way: a spreadsheet sits beside it, a paper fallback, or “we’ll do it as we always do”. I advise an organisation on digital transformation, from identifying needs to acceptance, so that the new way of working takes hold, fitted to its culture and to the pace of the people who will go through it.

From the slogan to the details, and back to a single decision.

Scroll and hover over the elements: one slogan branches into dozens of matters, and I bring them together into one route.

  1. Digital transformationA slogan that in practice means a great many different things at once.
    1. TechnologyThere is more and more of it, and it changes fast. I match it to the new version of the process, not to a list of products.
      1. Artificial intelligenceFrom analytics to agent-based systems. Order in data and processes first, the tool second.
        1. Generative AIIt helps with writing and analysis, but someone must answer for the decision and know the rules of use.
        2. AI agents and automationI automate what is described and simple. Automation merely speeds up a process nobody has described.
      2. Cloud and infrastructureWith care: total cost, an exit plan and dependence on the vendor.
      3. Collaboration technologiesCase flow, documents and shared work, so that the trail of decisions stays legible.
      4. Data and integrationsOpen APIs, standards and integrations, so that systems exchange data and people do not retype it by hand.
    2. Security and complianceObligations arising from regulations, and the organisation’s resilience. I start with a list of what needs protecting.
      1. Regulatory complianceKSC, GDPR, e-Doręczenia, KSeF: the obligations depend on the organisation, and are worth checking for specific use cases.
      2. Business continuityWhat happens when a key system stops working, and who knows what to do then.
    3. ImplementationThis is where it is decided whether the change succeeds: the project, the people and the vendors.
      1. Project managementScope, schedule, and a register of changes and decisions on the contracting authority’s side.
      2. Change managementThe organisation’s culture, the users and the pace at which they can go through the change.
        1. User adoption strategyWho moves to the new way of working, at what pace, with what support and in what order.
        2. Communication and trainingAnswers to an employee’s three questions: why are we doing this, what will change and will it work.
        3. Adoption and impact metricsMetrics for implementation, adoption and impact, each with an owner and a baseline.
      3. Vendors and contractsQuestions for vendors, a comparison of offers and a contract that does not tie you to a single manufacturer.

Krogis combines subject-matter knowledge with project experienceto provide peace of mind, security and compliance in change management projects

Questions worth knowing the answer to.

I put them to boards, secretaries, county heads and company presidents before decisions are taken and money starts to flow. If the answer to any of them is “we don’t know”, that is exactly where I can help.

  1. What should our organisation look like after the change, and what do we stop doing?
  2. Do the people who will work in the new system know why we are doing this and what will change for them?
  3. Who could lose out from this change, and were they at the table?
  4. How quickly can individual groups go through the change without overloading the organisation?
  5. How will we check in a quarter that the new way of working has taken hold?

What you get out of it.

Peace of mind

A change led according to a plan, with someone on your side who knows both worlds: the board and the technology.

Better results

People work in the new way, so the investment pays off in everyday work, not just in a presentation.

Fewer reefs and mistakes

An understanding of the culture and of the users’ pace reduces resistance, and the choice of technology and vendors avoids the traps, including dependence on a single vendor (vendor lock-in).

The cost of inaction. A system without a change in the way of working costs just as much as one that works, and delivers no effect. An advisor usually costs less than a single badly chosen technology, a single wrong vendor or a single trap in a contract.

Technologies and processes change. Adapting an organisation has always been hard.

The technology knowledge you need grows year by year, and the change is still decided by people. For over 20 years, in many organisations, I have dealt with precisely this combination: technology, process and adaptation. I advise boards, and the foundation is knowledge of IT.

  1. Knowledge I keep up to dateI follow technologies and regulations continuously, so that I advise on the basis of today’s state of affairs, not that of a few years ago.
  2. From business to IT and backI translate the problems reported by business users into the language the IT world understands, and the possibilities of technology into the language that users and the board understand.
  3. Technology matched to the new version of the processI gather knowledge so that I can match different technologies and their capabilities to the process in the form it is meant to take after the change, so that it delivers the intended business goals.
  4. An analytical approachA business view of technology and of users’ problems: the ability to identify and name what can be improved.

“He understands that effective transformation requires not only technology, but also the preparation of staff, the ordering of processes and consistent change management.”

Krzysztof Pijanowski, Deputy Director of the Department of Digitalisation and the Information Society, Marshal’s Office of the Łódź Voivodeship (Urząd Marszałkowski Województwa Łódzkiego). The full reference

A system that has been implemented is not yet an organisation that has changed.

Digitisation turns paper into a file. Computerisation introduces a system that supports a process. Only a change in the way of working makes an office, a company or a firm handle matters differently than before. The first two steps can be bought. The third has to be carried out together with the people.

  1. An EZD-class system that is up and runningis not the same as an office that handles cases differently and shares responsibility for documents differently.
  2. KSeF implementedis not the same as an invoice flow that has actually become shorter, rather than simply moved to a new window.
  3. ERP after go-liveis not the same as processes that no longer rely on spreadsheets and verbal agreements.

Four elements of change management.

A change has to fit the organisational culture and the pace of the user group. That is the key: the same change looks different in a department serving residents than in accounting or the technical team.

  1. Understanding the organisational cultureHow decisions are made, who really shapes opinion in the departments, how the organisation received earlier changes. A change that runs against the culture quietly slides back to the old way of working.
  2. Understanding the usersWho the individual groups are, which systems they use today and how well they know them, how much time they have and what they fear. This is the starting point for the pace and form of the change.
  3. Adoption strategyWho moves to the new way of working, at what pace, with what support and in what order, taking into account the group’s previous experience. A communication plan, training and metrics tailored to groups, not to an average user.
  4. Measurement and consolidationThree kinds of metrics: implementation (is it ready), adoption (are people using it) and impact (has something improved for the resident and the employee). Each has an owner, a baseline and a date for checking. Responsibility does not end with acceptance.

An employee asks themselves three questions.

Why are we doing this? What will change in my work? Will it work? A communication plan that answers only the first ends in quiet resistance. That is why I help the board and the heads of units answer all three in plain language, without generalities and without promising results we do not yet know. An honest “we believe in this direction, and here is why” builds more trust than certainty based on a forecast.

Who could lose out from this change.

No risk register has a column for it. Every change has those who gain and those who may feel redundant: the person who has been the only one to know a given system for years, the expert whose position rests on the existing way of working. I add this column to the stakeholder register and invite such people to co-create the solution before they become its reviewers. I work separately with heads of units and heads of departments, because they translate the direction into the daily work of their teams and must have a say in the decisions they will later enforce.

AI is a change too, not an add-on.

AI tools enter organisations faster than the rules for using them, often before management even knows. Whether they take hold is decided by people’s trust and by clarity about who is responsible for what, so this is a task for change management, not only for IT.

  1. Order firstAI will not fix chaos, it will only speed it up. Without ordered data, process owners and described rules, automation repeats mistakes faster than a human does. That is why we start with an inventory.
  2. Decisions before automationWhether the process is needed, whether it is simple enough, whether its variants and recurring exceptions have been described, and where a human still approves. Only then do we choose what to automate.
  3. AccountabilityA register of AI uses: where it is used, for which tasks and who is named as responsible for the decisions it helps with. Plus a responsible-use policy for AI and a named person who can say “stop”.
  4. Business measuresWhether the time saved goes to tasks of greater value to the organisation and its residents, not how many pilots, presentations and users we have.

Seven stages, one change.

Change management is not a separate project alongside the other services. It runs through the whole course: from identifying what the organisation has to checking that the new way of working has taken hold. We start with the inventory, and every later stage has its own page.

  1. IT systems and process inventoryWhat do we actually have? A starting point that also gives a baseline for comparison after the change.
  2. Needs analysis and workshopsWhat do we really need? This is where we get to know the organisation’s culture and its users.
  3. Digitalisation strategy and target architectureWhere are we going and in what order? Together with an adoption strategy for the people.
  4. Requirements and project preparationHow to describe needs so that the vendor understands them?
  5. Offer evaluation and vendor conversationsHow to compare the offers of different vendors effectively?
  6. Rollout, change and acceptanceHow to deliver the project, win people over and hold the vendor to account?
  7. Project coordination and keeping projects in orderWho keeps watch over the whole and the deadlines when there is no IT director?

Where it fits in my work.

Change management is the third point on the course: after the inventory and the strategy, before the requirements specification. I prepare the adoption strategy before the vendor joins the project, carry it out during implementation and check it after acceptance. The scope and timing are agreed after a first conversation.

A question for your next management meeting.

Who will this change affect most, and was that person at the table when we approved it?

Questions about change management.

How does implementing a system differ from changing an organisation?

An implementation ends with acceptance: the system works and meets the agreed scenarios. A change ends when people work the new way every day and the old workarounds disappear. The first is ordered from a vendor. The second requires an assessment of the culture and the users, a communication and training plan, and a check of the effect after go-live.

How should we talk to employees about the change?

Answer the three questions everyone asks themselves: why are we doing this, what will change in my work and will it work. Use plain language, do not promise results you do not know, and involve the heads of units before key decisions are taken, because they are the ones who translate the change into daily work.

How do we measure that the change has taken hold?

With three kinds of metrics: implementation (is it ready), adoption (are people using it) and impact (has something improved for the resident or the employee). Each metric needs an owner, a baseline from before the change and a date for checking, for example a few months after go-live.

Is it worth introducing AI in an office or a company?

It is, if there is a concrete goal, a described process and a named decision owner. Start by putting data and processes in order, by building a register of where AI is already in use, and by setting rules for its use. A pilot without an owner and without metrics usually does not make it into daily work. Legal obligations depend on how AI is used, so it is worth checking them for specific use cases, including with a legal adviser.

Does change management need a separate project?

Not always. For a small change, a communication and training plan is enough. For a large system, such as EZD or ERP, it is worth preparing an adoption strategy before the vendor comes in and running it in parallel with the implementation. We agree the scope after a first conversation, depending on the scale of the change and the organisation’s readiness.

Let’s talk about your change.

The first conversation takes 30 minutes and costs nothing. I reply within 2 working days.