Services
Development
Our Proof of Concept (PoC) demonstrates that your idea can be implemented, effectively testing the concept's viability in a real-world scenario. This process helps to identify potential technical hurdles and unforeseen challenges early on.
By building a small-scale version, you can test key Operaton functionalities and assumptions. This minimizes risks and prevents wasting significant resources on an unworkable idea. A successful PoC also serves as tangible evidence to secure stakeholder buy-in and investment. It allows for early feedback from users, ensuring the final product aligns with market needs. Ultimately, a PoC provides the confidence and foundational data needed to proceed with full-scale development.
Our joint path to proof of concept
Day 1
Gathering criteria – Together we will determine which evaluation criteria should be used to conclude the PoC to determine whether the PoC was successful or not. In other words, we will discuss your PoC goals.
Verbal presentation of the process or work routines – You tell us what you would like to see implemented in the PoC and provide us with context.
Scoping – Together we will determine what we consider realistic and thus outline the scope of the PoC.
Modeling – Together we will model your idea (ideally IT and the business department) and implement it further.
Day 2 – 4
Interfaces – Together we will clarify the solution’s interfaces. It may be necessary to conduct some internal research and bring in a suitable contact person. It also needs to be clarified what can be run via technical interfaces (APIs), how data can be processed, where users need to be integrated, and where the operation of interfaces (by bots) might need to be simulated.
Implementation – We work (possibly together with your internal team) on the creation of the software tools and architecture and regularly consult with other stakeholders.
Testing – We will conduct tests with users to ensure close coordination.
Day 5
Final implementation work and preparation of the final presentation
Presentation of the work results to decision-makers – We will outline the approach, advantages and disadvantages, and lessons learned from the proof of concept, while presenting the developed technical solution. We will also discuss the extent to which we have satisfactorily met the evaluation criteria from the first day.
Resources from you
Implementing a "true" proof of concept for your specific process in a short time requires collaboration with your team. Therefore, it's typically best to have people from the following areas participate:
Day 1 and last day
- Departmental staff (process experts)
- Decision-makers
Continously
- Internal software developers
- Machine and system managers (application owners) with interface knowledge
Day 1 and on case-by-case basis
- Infrastructure contact persons (administrators)
What are the deliverables?
A Proof of Concept (PoC) delivers a set of specific, tangible artifacts that go far beyond a simple presentation. These artifacts serve to prove technical feasibility, demonstrate business value, and create a solid foundation for the subsequent project.
Based on our approach, you can expect the following deliverables:
1. Executable Models and Prototypes
This is the core of the PoC. Instead of just talking about processes, they are brought to life.
- Runnable BPMN Process Model: A process modeled in BPMN 2.0 that is not only visualized but can also be directly executed by the Operaton Engine. It represents the core of the use case being tested.
- Executable DMN Decision Rules: If the process involves business rules, they are modeled as DMN tables and executed live in the PoC to demonstrate correct and automated decision-making.
- Working Prototype: A small, runnable application or service that integrates the modeled process and rules. This prototype often includes:
- User Task Forms: Simple user interfaces that show how human tasks in the process look and can be handled.
- Integrated System Connectors: Code that demonstrates the connection to one or more test or external systems (e.g., via a REST API).
2. Technical Artifacts and Code
The PoC provides all the code and configuration that was necessary for its implementation.
- Source Code Repository: A Git repository (e.g., on GitHub) containing all the source code for the prototype, including worker implementations, configurations, and test cases.
- Deployment Scripts: Scripts and configuration files (e.g., for Docker) that describe how to set up and run the prototype and the Operaton environment.
- API Definitions: If custom APIs were developed during the PoC, their specifications (e.g., OpenAPI/Swagger) are part of the deliverables.
3. Documentation and Reports
The results and the procedure are prepared for various target audiences (both technical and non-technical).
- Requirements and Results Matrix: A central document that clearly contrasts the initially defined requirements with the testing methods and the results (pass/fail) for each point.
- Architecture Diagram: A visualization that shows how Operaton fits into the customer’s existing or planned system landscape.
- Final Presentation: A summary of the results for management and stakeholders. It highlights the key findings, the business value achieved, and recommendations for the next steps.
- Installation and Operations Guide: A brief guide on how to operate the prototype and its associated environment.
4. Measurable Results and KPIs
To objectively prove success, quantitative data is provided.
- Performance Measurements: Reports that document measurable improvements, such as the reduction of process cycle time from days to minutes.
- KPI Dashboard or Report: A summary of the predefined Key Performance Indicators (KPIs) that shows the extent to which business goals (e.g., “reduce error rate by 15%”) were achieved.
Your next steps
Once the POC is complete, and it has been proven that Operaton is suitable for the technical requirements of your automation, further options are available to you on your journey into open source process orchestration.
