A new system built around your process, connecting the systems already in use, or modernising a core that no longer keeps up, with maintenance after implementation.
See the serviceMaintenance and development
Your system after launch in the care of the team that built it: fixes, changes driven by the process and regulations, component updates and monitoring, in an order you set with us.
Scope
What clients come to us with
Every change waits because nobody sets the order
Requests go by e-mail to the project manager, the chief executive and a programmer friend, and a minor fix and a rebuild of half the system sit in one queue. The order is decided by how loudly someone asks, and the department goes back to spreadsheets because it is quicker.
A regulation or the process has changed, and the system has stood still
A new rate or document template comes into force on a set date, and the company takes on a new partner or order type. The system handles things as they stood on acceptance day, and people once again make up the difference by hand.
The company learns of an outage from a customer
Overnight the system stopped sending confirmations, and the company hears about it in the morning from a customer. The system's components have not received a single fix since acceptance, because it was nobody's job.
Scope
What we do
Maintenance and development is the care of a system after launch, provided by the team that built it, so knowledge of it stays in the same hands. Maintenance: the system does what it did on acceptance day; we fix bugs, update components and watch how it runs. Development: the system does more or works differently, because your process or a regulation has changed. Taking over a system built by someone else is a separate scope, in the “Team and maintenance” service.
One queue of changes, and you decide the order
Every request goes into a register, a single list with a description, author, date and status. We divide requests into bugs, when the system does something other than what was agreed at acceptance, and changes, when it is to do something new. Bugs go before changes. The order of changes is set by a designated person on your side at the queue review, with our price for each item. A change driven by a regulation gets a list of the places in the system it affects and the date it comes into force, so it goes ahead of changes with no deadline. The department describes a process change in its own words, and we translate it into a scope and a price.
The path of every change to the live system
We check every change first in a test environment, a separate copy of the system for trials. Automated tests, which check the system with a program instead of by hand, make sure that what worked still works. Changes reach the live system in a release: a package of checked changes launched at an agreed time, with a description and a way back. Every release has an entry in the change log: who changed what and when.
Monitoring and component updates
Monitoring is a view of how the system is running: the system itself reports that it has stopped responding or has not completed its overnight processing, and notifies a designated person on our side and on yours. At an agreed interval you receive a report: what the system processed, where it stopped, how many requests came in and how many were closed. The system's components, the database, the server operating system and libraries (ready-made pieces of code), receive fixes from their vendors, including security fixes. We apply them in releases like any other change, so the system does not stay on an unsupported version.
Who does what on your side
The system owner decides the order of changes and receives the reports. The department reports comments and accepts changes in the test environment. The person in charge of access creates and removes accounts and confirms who in our team has access to the system and the data.
Scope
What you get
- A maintenance plan: the scope of care, the request path, the split into bugs and changes, the rhythm of reviews and releases, service levels (SLA) agreed in the contract, and the roles on our side and yours.
- A request register and a change queue with a price for each item, available at any time.
- Releases at an agreed time, each with a description, a log entry and a way back.
- Outage notifications and a regular report on how the system is running.
- System components on vendor-supported versions, with a list of versions.
Scope
How the work runs
- We write the maintenance plan before the system is accepted: scope, roles, request path, rhythm of reviews and releases. Outcome: a plan adopted together with acceptance, so from day one it is clear who is responsible for the system.
- We run the first weeks after launch. That is when requests are most numerous, so we review the queue more often and bug fixes go in outside the release rhythm. Outcome: a system stabilised in daily work and a first list of changes with prices.
- We maintain and develop at a steady rhythm. Queue review, release, report on how the system is running, component updates. Outcome: a system that keeps up with the process and regulations, with every change recorded in the log.
- We review the scope of care. At agreed intervals we check with you whether the scope, rhythm and roles match the number of requests. Outcome: a plan adjusted to the number of changes, or a handover of the system to your team with documentation and a period of joint support.
Scope
Questions the board should ask the maintenance contractor
- Who on our side decides the order of changes, and who settles whether a disputed request is a bug or a change?
- How quickly will we get a response to a bug that has stopped a department's work, and what does that time cover: acknowledgement, a workaround or a fix?
- How will we learn that the system stopped working at night: from a customer, from an employee or from the system itself?
- Who keeps track of the versions of the system's components, and what happens when the vendor stops issuing fixes for them?
- Who follows the regulations that change how the system works, and who confirms that after the change the system calculates in line with them?
- What will we receive when the contract ends: code, documentation, the change log, access, and by when?
The scope of care depends on what the system does and how many changes your process generates, so we set it in the analysis of the process and systems we start with.
Parent service
Systems and integrations
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
Custom systems
A system built around your process where a ready-made product would force a change in how you work, with code and documentation that belong to your company.
See the scope
Connecting systems into one whole
One place through which the ERP, CRM, industry system and spreadsheets exchange data on their own, with a description of each exchange and a view of whether it works.
See the scope
Modernising systems already in use
Your system rebuilt one part at a time without stopping work: knowledge of it recorded in tests, components on supported versions and code that can be changed.
See the scope
Operational portals
A place where a customer, partner or employee submits an application, order or ticket on their own and checks its status, while the service team sees every case in one view.
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