Can we order only the analysis?

Yes. The analysis can be delivered as a separate service. The result can be used for decisions and to compare proposals; the rights to use the documents are set out in the agreement.

Do we need to know in advance what software we need?

No. It is enough to know which processes take time or cause problems. The analysis helps decide whether you need new software, an integration or an improved procedure.

Who should be involved from our company?

A person who makes decisions about the project, the owners of the processes being analysed and some users who do the work every day. When existing systems are affected, someone who knows them is also needed.

What documents should we prepare?

The forms and templates you use, sample documents without sensitive data, internal rules or guidelines and a list of the software you use. We agree the exact list at the start of the analysis.

Is a new system always recommended?

No. If the problem can be solved by improving the procedure, configuring the existing system or adding an integration, the recommendation will say so.

How is the cost of the analysis set?

By the number of processes and departments, the systems to review and the level of detail required. After an initial conversation we send you the scope and cost of the analysis.

Can the project be delivered in phases?

Yes. The plan is usually split into phases, starting with the process that has high value and is achievable. Later phases are adjusted to the results.

Can ENOR continue with development?

Yes. ENOR can continue with the design, development and integration of the solution according to the agreed plan. The decision on how to deliver it remains yours.

DIGITAL TRANSFORMATION STRATEGY

Decide what needs to change before you invest in software.

We analyse your business processes, documents and systems to find where digitisation makes sense. We prepare a plan with priorities, requirements and delivery phases, linked to your organisation's goals and capacity.

Discuss your business processes What the analysis covers

From process map to planIllustrative concept

Current process

Request arrives by email
No common format
Entered in a spreadsheet
Retyped in a program
Approved by phone
No record of the decision
Report prepared by hand

Phased plan

Phase 1High priority
Online requests and approvals
Phase 2Medium priority
Integration with finance software
Phase 3After phase 2
Reporting from the system

Process analysis
Priorities and phases
Documented requirements

WHY WE START WITH ANALYSIS

An unclear process stays a problem even when it moves online.

Before development, the steps, responsibilities and exceptions of a process need to be understood. Digitisation should improve the flow, not copy every manual step without analysis.

The analysis answers

Where should we start?
What should change?
Do we need new software?
What can we keep?
How do we set priorities and investment?

Current process map — purchase requestIllustrative concept

Request by email
Spreadsheet entry
Approval 1
Approval 2
Order
Monthly report

Points identified

What it causesLost time and mismatches between the spreadsheet and the program.

What we askWhat is the main source, and where can it be entered just once?

Select a point on the map to see what it causes and what we ask during the analysis.

SCOPE OF THE ANALYSIS

What do we analyse?

Six areas reviewed together, because a process problem rarely has a single cause.

Processes and documents
The steps from request to completion, the forms and documents in circulation, and where they are stored.
Roles and responsibilities
Who submits, who checks, who approves and who stands in when someone is away.
Systems and integrations
The software you use, the data it holds and the possible ways to connect it, such as APIs or exports.
Data sources and quality
Where each piece of information is created, how complete it is and where it is duplicated or differs.
Customer and user needs
What customers and employees expect from the process: information, channels, speed and a clear status.
Constraints, dependencies and readiness for change
Budget, deadlines, internal rules, third-party dependencies and the time the team can give the project.

METHOD

How do we build the strategy?

01
We set the goals and scope of the analysis
We agree which processes, departments and systems are included.
02
We interview managers and users
We listen to the people in charge and those who run the process every day.
03
We document the current way of working
We map the steps, documents, systems and exceptions.
04
We identify problems and their causes
We separate symptoms from causes: delays, duplicate entries, missing information.
05
We assess the alternatives
We compare improving the procedure, existing systems, integrations and new development.
06
We choose priorities and the first phase
We decide where to start, based on value and feasibility.
07
We prepare the delivery and measurement plan
Phases, responsibilities, the initial estimate and success indicators.

There is no standard duration for an analysis. It depends on the agreed scope and on how quickly information can be gathered.

THE RESULT

What do you get at the end?

Depending on the agreed scope, the analysis ends with a document you can use for decisions, for preparing a proposal and for development.

The initial estimate of costs and timelines is based on the analysis. The final proposal is prepared once the project scope is confirmed.

Strategy document — contentsIllustrative concept

1Summary of the current situation
2Process map
3Documented problems and opportunities
4Proposed process
5Key functional and technical requirements
6Priorities and dependencies
7Integration plan
8Initial estimate of costs and timelines
9Success indicators
10Responsibilities of ENOR and the client

Initial estimate

A range of costs and timelines with clear assumptions, to decide on the next step.

Final proposal

A confirmed scope with defined phases, timelines and costs for delivery.

THE ALTERNATIVES

New software, an integration or improving the current system?

There is no single answer for every case. The alternatives are compared using the same criteria.

Improving the procedure
When it can fit: When the problem comes from the steps, rules or roles, not from a missing program.
What to consider: Needs internal agreement and new working habits; sometimes enough without new development.
Configuring or extending the existing system
When it can fit: When the current system supports the process and the team uses it well.
What to consider: System limits, licence costs and room for further changes.
Integration between systems
When it can fit: When the information exists but is retyped from one program into another.
What to consider: Depends on APIs, documentation, access rights and error handling.
Developing a dedicated module
When it can fit: When the process is specific to the business and no existing system covers it well.
What to consider: Requires development, testing and long-term maintenance.
Gradually replacing the application
When it can fit: When the current system limits the work but cannot be switched off at once.
What to consider: Needs a migration plan, a period of parallel running and a phased switch.

Custom development is not always the best answer. The recommendation is based on your process, systems and capacity.

PRIORITIES

We choose the first step by value and feasibility.

Each candidate process is assessed with the same criteria. The first step should bring value and be achievable with the current data and team.

Value and feasibilityIllustrative concept

First-phase candidate

Horizontal: feasibilityVertical: value

Assessment by criteriaIllustrative concept

Business impact: High
Frequency: High
Complexity: Medium
Data quality: Medium
Dependencies: Medium
Team readiness: High
Cost: Medium

High value and good feasibility: a strong candidate for the first phase.

Illustrative example with made-up processes and levels. In a project, the assessment is based on the information gathered.

The assessment is done together with your team. For complexity, dependencies and cost, a low level is more favourable.

Assessment criteria

01Business impactThe time, errors, costs or customer experience that change.
02Process frequencyHow often it runs and how many users it involves.
03ComplexityThe number of steps, exceptions and rules.
04Data qualityHow complete and reliable the required data is.
05Dependencies on other systemsIntegrations or decisions needed before starting.
06Team readinessAvailability of the users and of the person in charge.
07Cost to build and maintainNot only development, but also long-term use.

LEADING THE CHANGE

Change needs an owner and a way to measure it.

A good plan is not enough if nobody leads the change inside the organisation. The strategy also sets out how people are involved and how the result is measured.

What it includes

01A business ownerMakes decisions on rules and priorities.
02User involvementThe people who run the process take part in analysis and testing.
03A training planFor whom, when and in what format.
04A pilot where neededA trial with a limited group before expanding.
05Measurement before and after go-liveThe same indicators, measured at both points.

Possible indicators

Handling time
Manual data entries
Cases returned for completion
System use

From analysis to delivery: Software Development

FAQ

Questions about digital transformation strategy

Start with a well-founded plan.

Tell us where you face delays and what you want to improve. Together we will define the scope of the analysis and the results it should produce.

What happens after you write to us

1We read your descriptionWe look at the process, the systems you mention and where it gets difficult.
2We contact youWe clarify the questions we need to understand the process.
3We propose the first stepAn analysis, a limited trial or an estimate, depending on the case.

Please do not send confidential documents or data at this stage.

Decide what needs to change before you invest in software.

An unclear process stays a problem even when it moves online.

What do we analyse?

Processes and documents

Roles and responsibilities

Systems and integrations

Data sources and quality

Customer and user needs

Constraints, dependencies and readiness for change

How do we build the strategy?

We set the goals and scope of the analysis

We interview managers and users

We document the current way of working

We identify problems and their causes

We assess the alternatives

We choose priorities and the first phase

We prepare the delivery and measurement plan