Full-cycle Implementation
Where do we start from?
First off, we undertake a business survey, it's a preliminary stage, required to approve project objectives, scope, schedule and budget.
On this stage, our job is to listen carefully and grasp your issues and needs, help you streamline all the information and figure out what we can do for you, what our role would be. This doesn’t mean we will do exactly what you want us to. Our job is to provide you with something you actually need.
Once you analyse and process the information, think everything through long and hard, you may discover an issue, which was not immediately obvious, but it is exactly what has been hurting you the most. Our goal is to offer you a solution to these long-standing and painful problems. We do not want to convince a customer that they need a universal solution we have already implemented on numerous occasions and which can be delivered in a whisper. We strive to find an ideal solution for every individual case.
The survey may be conducted by our team on site, but most of the times, it can be done remotely by Skype or Zoom. If a project involves specialists from different cities or countries, online interviews are our only option. It should be noted that there aren’t but benefits to this format: it’s more convenient, fill-out forms are easier to send, interviews are easier to record.
Thus, over 1-2 weeks we conduct interviews with key decision-makers on customer end, and then we draft and unveil Project Concept – a document, outlining project goals and objectives.
Definition of objectives is often overlooked due to its apparent self-evidence, but it is actually a key pillar.
A simple “Implement 1C: ERP system” cannot be an objective, because an objective needs to have an external character, it has to define the benefits from the project for customer business. And, of course, it needs to meet the standards set by SMART criteria: be specific, measurable, achievable, relevant (i.e. it can be achieved by means of an automation project), and timed, in other words, it can be achieved within a calculated period of time.
Project Concept also describes:
its functional scope;
key tasks;
key methodologies;
end customers’ general requests;
specifics of business processes (affecting project plan and budget);
bottlenecks in business processes;
standard operating procedures for the project;
requirements to customer and contractor’s resources;
integration diagram;
time-schedule with timelines and budgets.
Requirements engineering and approval. Functional modeling 1С:ERP
Requirements engineering is a collaborative effort between Customer and Contractor through continuous interaction. To enable this effort, a shared-access project space is set up on Cinimex’ server based on Confluence collaboration platform (link to a page on Confluence+Jira).
First of all, we provide training on 1C: ERP for the Customer’s key users. To that end, a special database is installed on the Customer’s server, with examples from the Customer’s actual activities. All the lessons are recorded, and the records are made available for shared use, so that Customer employees can better learn and take in the new materials.
Business processes to be automated are analysed via modelling of Customer’s test cases on a prototype 1С:ERP solution. The customer’s team and key users participate in the testing of their future experience, which is enabled through a prototype solution and demonstration of its capabilities. Users get a chance to familiarize themselves with the future system. With Confluence, the conclusions of user's comparison of their existing practices and how things will be done in the future can be recorded easily and intuitively.
If it turns out that the prototype solution does not meet customer needs and follow-up refinements require additional studies, we will perform Functional modelling.
- Identification of bottlenecks in business processes and, if needed, formulation of requirements to re-engineering of business processes
- Modelling selected business processes in a prototype solution with standard functionality (no elaborated configuration) on a limited data sample (test case) involving Customer’s workgroup
1. The workgroup formulates requirements.
2. The consultants model a prototype solution based on data from the Customer.
3. The resulting model is discussed with the Workgroup to make modifications in it.
4. The final model may require several iterations.
- With that, the Workgroup gets an idea of business processes “To Be” in 1С:ERP, user scenarios, prototype functionality and workability in terms of business processes automation.
- Making a decision on the need for re-engineering of selected business processes to enable automation or increase their efficiency, and building a model of business processes “To Be” with reference to the prototype’s functionality and modifications to be made.
- Formulation of a list of necessary modifications in the prototype 1С:ERP solution.
Outcomes of functional modelling:
Specification of requirements, a model of business processes “To Be” with reference to functionality, interfaces and workplaces of the prototype solution.
List of functional gaps – desirable modifications in the prototype.
Database with a functional model.
During functional modeling, the Customer’s team is closely involved in the process and is well aware of what exactly we are doing at any moment of time. Every step of development can be tracked in Confluence. The coding stage is less transparent in this sense, as coders are gone to do the coding, and who knows what the final result of their work will look like. BUT we know how to do this job with proper transparency – every task is recorded in JIRA and associated with a corresponding business process in Confluence.
The following works are performed on this stage:
- Fine-tuning the prototype solution in accordance with the requirements listed in Project Specification.
- Testing all modifications.
- Design and approval of the Program and Methods of Testing.
- Testing and approval of test results.
Data required for testing is a limited volume of information, which should be enough to ensure validity of test results, but not more than that. Operational data isn’t normally used for testing, because operational data volume (regulatory, accounting and etc.) is built on the next – Implementation stage.
Approval tests are run by the acceptance commission, and all observations are recorded in Test Report.
Test Report observations may include the following:
1. Apparent failure to meet the required Technical Specifications in terms of configuration or software errors.
2. Additional requirements, which occurred to the Customer during the trials. They will be documented as additional works.
3. Capabilities of the prototype, which require additional discussion. No need for modifications or adjustments.
Beta Testing
Beta testing of the ERP system is run using real-life data in nearly real-life conditions, but with a test period and all data uploaded retroactively.
Beta tests are designed to try the ERP system out in a production environment:
- Identify and implement additional requirements to the ERP system, which for some reason were not outlined in the “To Be” model,
- Uncover and fix inconsistencies and other errors;
- Build user skills and understanding of methodologies behind the ERP system;
- Attain a satisfying system performance over the test period. Ensure that the system (and it’s not just a piece of software, but the combination of software/users/guidelines) is ready for deployment to production.
At this stage, the following works are performed by the Contractor and the Customer:
Installation of the working database and workstations;
Fine-tuning system functionality (such as, accounting policies or functional features of the system);
Software and equipment set-up;
User access permissions;
Design an approach to data transfer and reconciliation (normalization);
Design, test and implement data transfer procedures;
Test transferred data by users, reconcile (validate) and approve the transferred data;
Draft and approve user and administrator guidelines;
Draft and approve key user and administrator training programs;
Training and testing key users and administrators. Test runs of processes on fragments of real-life data involving users;
Other administrative issues.
Important: as a rule, the Contractor is responsible for data integrity only in terms of proper implementation of transfer methodologies developed by the Contractor and approved by the Customer, therefore, responsibility is shared:
- The Customer is responsible for consistency and conformity with the approved formats of source data (to be transferred).
- The Contractor is responsible for the correct implementation of the approved transfer methodology.
Unlike beta testing, on this stage, system outputs are used in reporting and enterprise management.
- System data relevance is maintained in real time,
- Legacy systems, replaced by the new ERP, may only be used to retrieve historical data,
- Reports may only be generated in the ERP system.
At the final stages, when the Customer accepts not just the model, but the whole system up and running, however thoroughly we scrutinize all the functionality, new system requirements will always arise (objectively – due to enterprise needs, and subjectively, usability-related). As a rule, these new requirements can be implemented as part of follow-up monitoring. But there can also be latent defects, which cannot be uncovered before the system is deployed into production. They can manifest themselves months after deployment as a consequence of a combination of factors. It’s a normal thing, and we are contractually obliged to remedy such latent defects under the guarantee, which spans from 9 to 12 months. This work will be performed at our expense.
Implementation of an ERP system at an industrial enterprise is a challenging task. ERP is essentially the nervous system of the enterprise, and the automation project can be compared with implantation of a central nervous system into a living body.
Such projects come with numerous organizational tasks, such as, fitting the project into stakeholders' schedules, coming up with unorthodox methodologies, uncovering layers of non-formalized processes, finding ways to blend legacy knowhow with brand new approaches of the new system; motivating staff despite the increase in workload, and so on.
Of course, between our daily hassle and chaotic schedules it is not easy to find the time to prevent problems that haven’t even happened yet. However, it is better to prevent than to treat. We not only need to know all the risks behind the project, it is important to properly assess their probability and impact. You need to devise an action plan for risk mitigation or reduction (risk management strategy).
Our best practice is as follows.
At the preliminary stage, the project manager reviews a special register of typical risks to assess which ones of them can occur in this particular project. Next, they specify these risks in the project charter and suggest a strategy to mitigate them. The same process needs to be repeated before moving on to a new stage. Also, when putting together a weekly report on project progress, the project manager should address the risks in the report – whether any other issue or threat has come up, and if yes, how they are going to address such threats.