A. Template Design Studio (TDS)
A windows forms client application used to configure the process templates.

It is mainly responsible for:

1. Process flow definition
2. Security/Role definitions
3. Business object linking, business object default setup, CRUD library generation and compilation
4. Alert implementation, alert notification setup, alert escalation process template linking
5. Data input form design
6. Template relationship setup (flow dependencies etc.)
7. Template Import/Export relationship setup

B. Process Run Time (PRT)



This is the run-time client application used to manage/act on the business processes.

Two client applications are currently available targeting windows forms and asp.net. The client you use will be determined by the requirements of your business process. In the automotive industry where we use QT to simplify the recording of production, reversing of production, scrap, etc. we use barcode scanning, label printing, integration with physical hardware (such as scales – through the COM port) the windows forms client is the choice. In the banking industry, where there are 30 000 + users, the web portal will be employed. A combination of both clients can be used working with the same process instance (i.e. if at the office over the LAN you can use the Windows Forms client that is more responsive, while when you’re away from the office you can use the web portal).

A dashboard is provided showing all the outstanding user actions.

C. Business Object Execution Engine



This is the component responsible for execution of business objects at certain points in the business process. The component applies default values for object properties and applies process instance data to the relevant business object/s before execution.



D. Process Flow Engine



This is the component responsible for managing the flow in the business process. It is also responsible for managing relationships between process instances, such as sub-processes and flow dependencies (merging and splitting). When complex business rules have to be applied in order to determine flow direction etc. the Process Flow Engine will call on the Business Object Execution Engine to make the decision.

All configuration and setup of process templates are done with the Template Design Studio (TDS). With the designer users can map out process flows, define roles and responsibilities, setup alerts and notifications, design web and/or windows forms input forms, define process relationships (sub-processes, flow dependencies), register business objects for execution at certain point/s in the process (multiple objects can be executed), map process data inputs to business objects (and setup defaults), configure process flow business rules and more.

Process instances can be launched and administered from the QT Web Portal/QT Windows Forms Client/Outlook. Users are notified of their tasks by email/SMS. A dashboard will display all outstanding actions that a user is tasked with and allow the user to easily perform the action. Tasks in the dashboard are separated into current tasks (within time constraints) and overdue tasks.

At any point in time an overview on all process instances are available to enable a global overview. Of course, all process metrics such as: who performed a task, when it was it was completed, time/s between process track points, who is always late, who is always early, averages, etc. are available and exposed as part of reporting configuration.

Some features

  Configure your own process
  Setup alerts, escalation of alerts and notifications
  Launch process instances on alerts i.e. resolve alert conditions with predefined process
  Manage sub-processes, flow dependencies and relationships
  Assign unambiguous responsibility
  Windows forms client and/or web portal for user action
  Invoke business objects
  Powerful rules engine direct complex flow decisions
  Define user input forms targeting the web and/or windows forms
  Barcode scanning enabled


Consider a hypothetical business process where a quotation is requested from a supplier, the supplier responds with a quote and delivery time, a purchase order is generated in the ERP system and sent to the supplier, the supplier accepts the purchase order and confirms delivery time, the ordered goods are placed in a container, moved onto a ship, moved from the ship and cleared by customs, transported by truck from the harbor to the warehouse, goods are received into the ERP inventory system, payment are made to the supplier according to supplier terms.

If, for example, we placed an RFID tag on the container (and received the RFID signals) we could track the progress of the container/order. By knowing this information huge benefits can be derived:

We know if delivery time estimation is accurate. It could potentially have a huge impact if we break contract terms on delivery of manufactured parts that depend on this order. We might be able to remedy the situation (for example, using airfreight to fly in an emergency order) using this information.

We can automate normally manual procedures saving on time and resources (human) required to perform tasks. When we receive the signal that the container has arrived at the warehouse we can automate the receiving procedure by automatically moving the goods into inventory against the purchase order.

The tracking of the physical items is an integral part of the business process and seamlessly integrated in QT. The system understands that tracking signals can come from multiple sources such as RFID, Barcode. Manual Confirmation, EDI and provides a single Signal Interface into which all tracking signals feed.

From the Template Design Studio (TDS) point of view there is no difference between setting up a process for BPM or for physical tracking. Additional properties will have to be configured in the TDS to enable physical tracking.

The system was initially developed for RFID Tracking. Right from the start it was realised that the fundamentals of process flow remains the same irrespective of the physical object being tracked i.e. Part, Asset, Employee, Order, Document etc.



For this reason a process flow engine was developed to facilitate the tracking process. This flow engine is generic in the sense that any object existing in the database can be linked to the predefined flow.

We understand that tracking signals can come from multiple sources (RFID, Barcode, Manual, EDI etc.) and as such we have created a single Signal Interface into which all signals can feed from the middleware layer (layer that transforms raw signal data into a format that our system can understand). When process rules are violated System/User-Defined Alerts and Notifications can be triggered, ensuring that pro-active action is taken to resolve the problem.

Execution of Business Objects can be triggered on receipt of signals. This facilitates the extended power of the solution as many normal business processes can now be automated.

Tracking of objects in QT can take 2 forms:

1. Process



Used when an object is tracked according to a pre-defined process.



2. Random



Used when we want to track the location of an object, but we don’t have a pre-defined process according to which it will be tracked i.e. the object can arrive at random at any track point.



It is important to note that the same object (Token/Tag) can be tracked simultaneously with multiple random and process templates.




Typical tracking patterns (i.e. patterns that occur repeatedly when tracking objects) that the system caters for are:



1. Containerisation/Piggybacking



A physical object being tracked is moved into a container that is tracked according to the same/another tracking process. By virtue of the container receiving a tracking signal, the tracked object should also receive the signal i.e. it is piggybacking on the container’s signal.

2. Entity Association



On receipt of the tracking signal for a tracking instance, we expect to receive the signal for another tracking instance within a pre-defined period of time. As an example, consider an employee removing a notebook from a building. If the notebook and employee is RFID tagged, the system will expect to receive a signal for the employee when a signal for the notebook has been received. If this is not the case alerts can raised.

3. Zoning
can be setup in the system.

The system will use the two last known tracking signals to map the location of an object to a zone i.e. the system can detect direction of movement.