ISIS Papyrus Software

Posts Tagged ‘process management’

Background of Adaptive Case Management

In value proposition on March 30, 2010 at 2:09 am

Business Process Management (BPM) has come to be viewed from several angles. The overwhelming force of IT and technology has led to the notion that BPM is merely a tool for automatic processing where human interaction is to be avoided at all cost and is at best regarded as a necessary evil. But the complexity of the underlying rigidity of this approach has by far outgrown its benefits. The processes set up on hard-coded models after lengthy upfront analysis have proven to be inadequate for real-world business cases and the inherent dependencies have proven prone to quick adaptation and smooth maintenance.

Yet initially business processes have been all about human activity and completely separate from technology. A business process is simply a sequence of activities followed by individuals in a business to achieve some business goal. This sort of business processes has been around as long as businesses have existed and long before computers or information technology were invented. The fundamental problem now is that most IT models are based on well-defined goals in rather static work settings. In reality, most business users have to deal with ill-defined problems and dynamic, if not to say, chaotic environments. They often have to improvise and to cope with shifting conditions and need to learn about the goals while going through the process.

Therefore it appears logical to shift process ownership back from IT to business to add true business value. Again, the approaches are manifold and the existing terminology adds more to confusion than to clarification. With this in mind the term “Adaptive Case Management” has been coined as a starting point for discussions about concepts of self-learning systems that can adapt to user input in real time. Some initial considerations can be found here and here. There will also be an exciting opportunity to hear more about “Adaptive Process and Empowerment” at this year’s ISIS Papyrus Open House and User Conference, where Chief Architect Max J. Pucher will elaborate more on this topic in one of his famously pronounced addresses.

Avoiding Constraints Of Conventional BPM

In benefits on November 10, 2009 at 3:05 am

When analysts come to the conclusion that end-user organizations want to be able to change their processes considerably faster than they actually can and add “They want to move to environments in which there’s a lot more self sufficiency on the part of the end user to configure the process,” this clearly reflects the constraints of currently used rigid process models.

To avoid such limitations ISIS Papyrus focuses on the business needs to respond quickly to dynamically changing customer requirements. The built-in process engine of the Papyrus Platform does not use simplistic procedural flowchart graphs to define the process but instead the Papyrus BPM is state and event driven to avoid problems associated with parallel activities, human interaction management and the rigid sequence of a procedure. This state and event driven process does not require complex decision blocks or listen-for-event-loops. All changes of the process are defined in the Desktop and stored in the central WebRepository.

Papyrus process management is flexible, understands the needs of users and supports knowledge-intensive business processes in combination with business communication. Users define the user interaction with the Activity Recorder and Natural Language Rule Editor and train the process sequence with the User-trained Agent. Collaboration, check-in/check-out, versioning, project management are generic platform functions. Other major benefits include:

  • Less process tuning and correction because an unforeseeable event sequence does not invalidate the process
  • Changing the state engine and event definition of one item updates automatically all processes using this item
  • Changes of the process do not require Java coding
  • No programming of dialogs required