Custom systems

A custom system is a program built from scratch for one process in your company: it accepts data in the form in which it arises at your company and handles each case by your rules. A ready-made product is a program for many companies, sold with a licence and configuration, that is, settings within the limits the vendor has provided.

First we check whether a ready-made product would be enough. It is enough when your process looks the way it does in most companies: accounting, HR, ticket handling. Then we recommend buying and configuring it. Building from scratch makes sense when:

• the process is the company's edge and the product would force a change to it;
• the ready-made product would need so many modifications that it would lose the vendor's updates;
• the company's data and rules do not fit the product's data model, that is, the objects and relationships the program can record.

We write the scope from the process: step by step, from the event that starts it to the result the customer or department receives. For each step we record whether the system performs it on its own, supports a person, or leaves it outside the system. Connecting to programs already in use and modernising your own system are separate scopes.

We build in stages, and each stage goes to the department that works with it. The first covers the step that takes people the most time, and it works in daily operations before the next one is built. The department reports what gets in the way, and you assess a working part before commissioning the next.

Source code, the text of the program that developers read and change, sits from day one in a repository, a store of code versions to which your company has access. After acceptance the code and documentation belong to your company. The documentation describes the process, the data, running the system and making changes, so that another contractor can read it.

We agree the change path before the start. Every change has a description in the language of the process, a price and a check in a test environment, a copy of the system kept apart from daily work, followed by acceptance by the department and an entry in the change log. Automated tests, programs that check the system after every change, protect what already works. Ongoing care after launch is a separate scope: maintenance and development.

1. We write down the process and check ready-made products. We talk to the people who run the process and compare it with what ready-made programs offer. Outcome: a recommendation of what a ready-made product will handle and what needs building, with a scope for your approval.
2. We design the system and divide it into stages. We set the data, rules and screens for each step of the process, and the department that will accept each stage. Outcome: a design and a stage plan approved before the first line of code.
3. We build stage by stage. Each stage is built in your company's repository, goes through tests and is handed to the department that works with it. Outcome: successive steps of the process run by the system, with the department's comments going into the next stage.
4. We hand over the system. We complete the documentation and teach designated people the change path. Outcome: the system, code and documentation in your company's hands, and a decision on who runs maintenance.

1. Which parts of our process would a ready-made product handle, and why do you propose a build anyway?
2. Who owns the code and documentation after acceptance, and can another contractor take over the system without your help?
3. After which stage will the first department start working in the system, and what will we see before deciding on the next?
4. What does the change path look like after launch: who describes a change, who prices it, where is it checked and who accepts it?
5. Where does the system run, who has access to its data and what happens to the data when the contract ends?
6. What stays outside the system, and who will do it after launch?

Answering the first question requires comparing your process with ready-made products, so we start with a process analysis that ends with a recommendation: a ready-made product, a build, or a combination of both.