Select Page

Jiver - a BPMS class toolset

Different look at processes

Jiver System is a set of BPMS-class tools that support modelling, testing, implementation, execution and monitoring of business and technical processes in a company.

Jiver

If you are in the process of choosing this type of tool, answer the following questions:

  • Do your processes models consist of basic, easy to separate and reusable sub-processes?
  • Are the projects of your processes always trying to predict multiple alternative paths?
  • Do you often need to make lots of changes in the processes and can they change dynamically?
  • Is process change testing a significant challenge and generates high costs for the company?
  • Is process change implementation associated with high business risk?

If the majority of your answers to these questions are YES, then refer to a different approach for modelling and implementing of processes that Jiver system provides. It grew out of years of experience we have gained in the design, implementation and development of BPMS-class systems, mainly in the domains of Provisioning and Order Management.

Jiver - system's architecture

Philosophy

Jiver is a system that carries out processes differently from a classic BPMS. The majority of classic BPMS solutions use a process-driven approach, in which process definitions are static and known in advance. Jiver uses rules-driven approach which is characterized by dynamic building of process instances based on the input data, decomposition rules and accessible set of elementary sub-processes.

Comparison of classic BPMS solutions with Jiver system

 

Process building

Classic BPMS

Processes are static and known in advance.

Jiver System

Process instances are built dynamically based on the order data, decomposition rules and a set of reusable sub-processes.

Process modification

Modification of existing process definitions required.

In most cases only decomposition rules will be modified.

Process handling

Changing the processing order of process operation requires the modification of the definitions of existing processes.

The order of processing activities / implementations is configurable and determined at the stage of decomposition based on the information stored in the rules.

Testing

Any change in modified or existing processes requires comprehensive and expensive tests.

In most cases, the processes are assembled from previously tested reusable parts, which can significantly reduce the testing phase.

The approach favoured by Jiver introduces great flexibility in building processes, optimizing the production costs and minimizing business risks. Below are the pros and cons of this approach.

Pros:

  • processes are modelled from small, functionally autonomous and tested elements,
  • oriented towards meeting business rules and needs,
  • optimization of processes and imposition of reusability,
  • optimization of production costs and minimization of business risks.

Cons:

  • process modelling requires a more thorough analysis and implementation of rules,
  • requires greater competence from analysts and programmers.

Jiver system handles the processes automatically. However, it is possible to integrate with workflow systems that provide support for human tasks. Jiver system supports Aperte Workflow and Jira solutions.

Why trust us?

Jiver was developed using the knowledge and experience gathered during the creation and maintenance of Provisioning and Order Management systems for our clients.

What makes us different?

  • Expandable domain modelThe system does not enforce its own, specific, closed data model. We created a mechanism that enables adapting the model to the client’s expectations and needs. Thanks to this, your company’s own list of terms (specific for its field of activity) can be implemented and used in our system, thereby eliminating the need to constantly translate business concepts for the system-specific model (and vice versa), which facilitates communication between business analysts and technical personnel.
  • Flexible processesIn contrast to the classic BPMS engines that allow you to define only the static definitions of processes, a process instance in Jiver is built dynamically during the decomposition phase of the order fulfillment, based on data received in the order from an external system. An order process instance is built with reusable fragments that implement specific actions on products or services, such as activation, modification and deactivation – according to the domain model which can be designed specifically for your business. The system also supports the activation of multiple products/services in a single order. Such flexibility allows for better structuring of processes and reduces the effort needed for their design, implementation, testing and maintenance.
  • Open architectureEach of the embedded system modules can be replaced or customized to customer’s specific requirements, without affecting the other system components.

System features

  • flexible configuration of the system – allows for quick and easy adaptation to specific customer’s requirements. We can customize the system according to your needs;
  • adaptation to the character of the company – the application provides a flexible and easily extensible domain model. This model may be a reflection of the concepts used by both business analysts and technical specialists – allows you to easily transfer the requirements formulated by the business to the rules and processes in the system;
  • easy configuration of processes – flexible decomposition of business orders into technical processes using Drools Rule Language and a clear, intuitive BPMN2 web editor for designing and implementing technical processes;
  • easy management – configuration of system parameters from the web interface;
  • process monitoring – advanced web-based processes monitor (including process state management – restart or skip steps in the process);
  • modular architecture – allows for the exchange of individual components (e.g. business rules engine) and helps to extend the functionality of the system. If you do not want to use Drools, the application can be easily integrated with any of the JVM-based scripting languages, such as JRuby, Jython, MVEL etc. We can also design a dedicated rule language tailored to the client’s specific needs (Domain Specific Language);
  • high performance processing – the system processes orders from external systems in a multi-threaded and asynchronous manner, allowing you to achieve high throughput. Easy setup allows us to fine-tune the system to the capabilities of the company’s hardware;;
  • high scalability – very easy extension of system capacity by adding additional application nodes (machines);
  • robustness – high resistance to errors and failures, including the ability to automatically cope with processing errors;
  • transactionality – by allowing compensation of technical actions, carried out in external systems during activation of products or services. The compensation is configured using the rule language to allow the withdrawal or cancellation of even the most complex orders;
  • support of standards – technical connectors ensure easy integration with external systems – we support SOAP, HTTP(S), XML, JDBC, FTP/SFTP, as well as direct ESB Software AG webMethods integration;
  • cohesion – a single, intuitive interface for all system modules;
  • convenience of access – the web interface requires no software installation for users and administrators;
  • rights control – a built-in authentication and authorization module (SSO).