The dyPAS (dynamic Process Application Server) developed by Proceedit is being recognized as the best Methodology & Technology for BPM Process Standardization

With the traditional IT approach (tailor made projects for each customer) and the usual way to use BPMS technologies by BPM technologists (almost all the configuration of the process class, personal tasks forms, data model, business rules, automatic tasks, … is made on the platform), the effort for massive BPM adoption and the technological complexity generated (see next figure) by hundreds of Process Class that are required to deploy and maintain is simply not possible to afford by mid and small size organizations.

proceedit considers that the clue to overcome these tremendous barriers of effort and complexity goes through a drastic change of paradigm in the BPM Industry. Indeed, We stand for applying the new value chain Co-development > Standardization > Reutilization > Low Cost that is, in our opinion, the only way to achieve a massive, affordable and sustainable BPM Process adoption, especially when we are talking about the mid/low-end market.

After 4 years of intensive development, piloting and testing efforts, proceedit announces the availability of the first full operative version (already in operation) of its methodological and technological platform dyPAS (dynamic Process Application Server) that, combined with any of the BPMS platforms available in the market today, provides an easy to use and maintain, flexible, robust and resilient engine for BPM Process Classes standardization.

The dyPAS outcome is to manage in a fast, flexible and efficient way the definition, refinement and evolutionary change of the forms, views, data models, and workflows trough the usage of dynamic parameters & business rules associated with the automation of business processes. 

Using our dyPAS technology for BPM Process Classes development, we apply several methodological rules:

•  Only one Process Class for each business process type,
• Only one Form Class for each Process Class,
• Real time dynamically generated Views of the Process Form Class customized on the fly at the instance level depending on: Process Task Class, Customer, User and Device requesting the form, and other contextual variables, parameters and business rules,
• Unified Process Data Model (Business Ontology) for all Process Classes
• Continuous unique version of each Process Class serving all customers but customized on real time, 
•  ... and till nearly 40 standardization rules.

And this all managed from a single centralized system which handles the real-time behavior of all the forms and workflows of all automated processes in one or more organizations, both in terms of:

• What information to display and how to manage it,
• The Process Forms Views behavioral characteristics in front of the User depending on: the Process Task, the Client, the User and the Device from which the user accesses the system, and
• The behavior of the workflow in each use case, depending on the real time business rules constructed and served on the fly, according to the present business scenario.

The above behavior is sustained in the architecture showed in the figure here below, being the main applied concept the separation in different areas and supporting platforms (BPMS and dyPAS respectively) what refers to Workflow management and what refers to the Data, Forms and Rules management.