An analysis of the process and the systems, ending with a recommendation and a scope of work: reorganise the process, connect the systems you have, or build a new one.
See the serviceStep-by-step implementation plan
Implementation stages arranged so that each one ends with something that works in the company, with the people on your side, the board's decisions and the conditions for moving to the next.
Scope
What clients come to us with
A schedule in which the first result comes at the end
Every phase in the contractor's schedule ends with a document or the acceptance of something nobody in the company uses yet. The board receives progress reports and has no way to check whether the project is going well. If the money runs out before the last phase, nothing is left in the company.
An implementation that stalled halfway
The first part of the system works, the rest stayed on paper because the project manager left or the budget changed. Part of the department works in the new system, part in the old one, and the data is in both. Nobody can say what is left to do and in what order.
One tool for several companies or branches
The group wants all its companies to work in one tool and in one way. Still open: which company goes first, what the others do during the transition and who declares that a company is ready. Without a plan, each company negotiates its own exceptions and the shared standard falls apart before the implementation ends.
Scope
What we do
An implementation plan is a document that divides the build of a system or automation into stages. In our plan a stage ends with something that works in the company: a group of people does part of their work in the new system, or one manual task disappears. A document, a technical design or a presentation does not close a stage.
Manual work sets the order of the stages. From the process analysis we know where the hours go on retyping, checking and waiting; the more of that work a stage replaces, the earlier it comes in the plan.
Each stage has three descriptions. People on the company's side: who provides data and access, who checks the result against their own work and who accepts the stage, named by role. The board's decision points: the moments when the board chooses whether to go on, change the scope or stop, and what it needs to know to choose. Conditions for moving on: acceptance criteria, verifiable conditions which, once met, mean the company considers the stage complete. An example of such a condition: the department works in the new system for an agreed period without going back to the spreadsheet.
The plan also describes the transition period. A test environment is a copy of the system on which changes are checked without touching real data. A pilot is a launch in one department before the system reaches the rest of the company. Data migration is moving data from the old system to the new one, after which the company works in both at once for a time. Each of these points has a responsible person and a completion condition in the plan.
The implementation under the plan can be run by ALIAX or by another contractor. Every stage has a described scope and acceptance criteria, so any contractor can submit an offer based on the plan, and the board compares offers stage by stage. Whether the system can be built in this scope and for what money is settled by a feasibility study; that is a separate scope.
Scope
What you get
- An implementation plan in stages: the scope of each stage, what works in the company once it is complete and which manual work it replaces.
- Staffing on the company's side: the people who, in each stage, provide data, check the result and accept the stage.
- A list of board decisions: the points at which the board chooses the way forward, with the options and the information needed to choose.
- Acceptance criteria for each stage and a description of what happens when they are not met: repeating the stage, narrowing the scope or stopping.
- A scope description for contractors: a plan on which any contractor, including one other than us, can base an offer.
Scope
How the work runs
- We establish the starting point. We take the recommendation from the analysis or an existing scope description and, with the people who run the process, list the manual tasks the system is to replace. Outcome: a list of tasks with the people who perform them today.
- We divide the implementation into stages. We assign each task to a stage, order the stages by the amount of manual work and check that each ends with something that works. Outcome: a draft of the stages with a description of what works after each.
- We staff the stages and describe the decisions. For each stage we add the people on the company's side, the board's decision points and the conditions for moving on. Outcome: a plan with staffing, decisions and acceptance criteria.
- We discuss the plan with the board. We mark what the board approves at the start and what only at later decision points. Outcome: a plan ready for approval, the basis for an offer from us or from another contractor.
Scope
Team experience
Members of the team led the implementation of JIRA, a system for managing tickets and tasks, together with its standardisation across a group of companies in the banking sector.
Scope
Questions the board should ask the implementation contractor
- After which stage will the first person in the company stop doing something by hand, and what will it be?
- What must happen for us to consider a stage complete, and who on our side signs the acceptance?
- Which people from our company does each stage need, and for what?
- What remains in the company, and does it work, if we decide to stop after the first stage?
- In which stage do you move the data from the old system, and how long do we work in both at once?
- Which decisions do you leave to the board, which do you take yourselves, and when will we hear about them?
- Can another contractor price and take over the next stage on the basis of this plan?
The order of the stages comes from where manual work goes in your process today, and that is established by the process analysis we start with.
Parent service
Technology advisory
Book a meeting
Book a conversation about the problem
You describe the process or system that no longer keeps up and what has to change. The conversation costs nothing.
Phone: +48 455 406 404
Systems diagnosis and review
A description of what your systems do today, what slows work down and what can be put to use, ending with a scope recommendation on which you can base the implementation decision.
See the scope
Technology strategy
A direction for the company's systems over several years, written so that the board knows which systems stay, which are replaced, in what order and what it pays for.
See the scope
Feasibility study
An answer before a large expense: whether the planned system or automation can be built in the assumed time and budget, on what data and with what constraints.
See the scope
Technology due diligence
A report on the state of the systems, code, data, licences and IT team of the company you are buying, with the risks and the cost of putting things in order, before the deal is signed.
See the scopeHow we start
A conversation about the problem
You describe the process or system that no longer keeps up and what has to change. The conversation costs nothing.
Analysis under an NDA
We examine the process and the systems and hand over a recommendation with a scope of work. You know the scope, deadline and price of the analysis before it starts.
Offer
You receive the scope, team, schedule and price of the implementation. You decide whether we go ahead.
The cost of the analysis is credited towards the implementation if you order it.
Phone: +48 455 406 404 E-mail: contact@aliaxit.com