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 serviceFeasibility 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.
Scope
What clients come to us with
A supplier's offer is waiting for signature
A supplier has sent an offer for a system. The department that is to use it wants to sign, and finance asks how anyone knows it will work. The offer assumes the data is ready and the current systems can be connected, but nobody on the company's side has checked. The board needs an assessment from outside the department that wants the purchase and outside the firm that wants to sell it.
Automation on data nobody has looked at
The company wants to move manual work into automation: document recognition, answers to enquiries, invoice checks. The plan assumes the data sits in systems and is of good quality. In reality part of it is in scans, part in mailboxes and part in each department's spreadsheets. Someone has to check whether the automation will work on the data the company actually has.
Build, buy or tidy up: everyone has their own numbers
The IT department wants to build a system around its own process. The operations director prefers a ready-made product because a similar company uses it. A third person says it is enough to change the order of work and no system is needed. Each side has its own calculations that cannot be set side by side, and the decision waits.
Scope
What we do
A feasibility study answers one question: can what you intend be done under the conditions you assume. We write down the intention and the assumptions it rests on separately, because the assumptions are what we check.
We check four areas. Data: whether it exists, where it sits, what quality it is, who owns it and whether it may be used for this purpose, including when it is personal data. Systems: which of the current ones must connect to the new one, what route for data exchange each offers and on what terms of the vendor's licence. Regulations: which apply to the intention and what they change in the scope, for example cybersecurity rules such as the Polish National Cybersecurity System Act (KSC) and NIS2, personal data rules (GDPR) or your sector's requirements. A legal opinion, when needed, is issued by a law firm. People: who will use it, who will maintain it after launch and whether the people the plan cannot succeed without have time for it.
When the answer depends on whether the technology can cope with your data, we run a trial: a small piece of the system on a slice of real data. The trial is meant to show where the plan is thinner than assumed, before you pay for the whole.
We compare the options on the same criteria: build around your own process, buy a ready-made product or tidy up the process without a new system. For each option we record what share of the work it covers, what data and people it needs, which constraints it triggers and what must be true for it to succeed. We record each risk by name, with the person on your side who keeps an eye on it.
The study concerns one intention. A review of all the company's systems, a technology direction for years ahead, an implementation plan after the decision and an assessment of the technology of a company being acquired are separate scopes.
The result is an answer for the board: yes, yes with conditions, or not in this form, with the reasoning on one page and the details in appendices.
Scope
What you get
- A description of the intention and a list of assumptions: what is to be built, for whom, in what time and budget, with the result of checking each assumption.
- An assessment of feasibility in four areas: data, systems, regulations and people, with a list of constraints.
- A comparison of options: build, buy or tidy up the process without a system, on one set of criteria, with a recommendation and its conditions.
- A register of risks and conditions for success: what must be true on your side, who keeps an eye on it and what to do when a condition is not met.
- The result of the trial on data, when it was in scope: what worked, what did not and what follows for the decision.
Scope
How the work runs
- We write down the intention and the assumptions. We take the plan as it stands, a supplier's offer or a note from the IT department, and list what it rests on. Outcome: a list of assumptions to check, in order of their weight for the decision.
- We check the assumptions at the source. We look at the data where it sits, check the systems for data exchange and licensing, set the regulations against the scope and talk to people about their daily work. Outcome: a list of constraints and what each one changes in the plan.
- We run a trial on data when one is needed. Outcome: evidence instead of an assumption at the point on which the most depends.
- We compare the options and hand over the answer. We discuss the options with you and the board, together with the risks and conditions for success. Outcome: an answer based on checked assumptions, even when it is “not yet” or “differently from the plan”.
Scope
Questions the board should ask the feasibility study contractor
- Which of our assumptions about time and budget did you check at the source, and which did you take from the offer?
- Has anyone looked at the data the system is to work on in our systems, or only in their description?
- Which of the current systems must connect to the new one, and is each such connection possible on the vendor's terms?
- What must be true on our side for the plan to succeed, and who will confirm it before the contract is signed?
- Which option did you reject and on what basis: the build, the ready-made product or a process change without a system?
- Which regulations change the scope, and are their requirements in the comparison of options, or will they only surface at acceptance?
- Does the contract allow for the result that the plan makes no sense in this form, and how do we settle the bill then?
The order in which assumptions are checked depends on the process the expense concerns, so the first step is an analysis of that process and of the systems it runs on today.
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
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 scope
Step-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.
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