How can we make one thing available in many different places without compromising its integrity?
At the present, any information is scalable by means of computers almost in a real time; unfortunately this does not mean that the information would have the same meaning and value everywhere. Even within one relatively integral environment such as a company, not all processes are always scalable to all business units or departments. There are some positive exceptions to it but the majority of information to be scaled without losing required integrity and application quality, also needs to be modified, often directly during the process of scaling.
A system which is capable of fast and effective modification of scaled information is also capable of generating fast and effective scalable impacts. Here are some of the modification criteria during scaling:
Phasing and Segmentation - Enablers of Systemic Scalability
A system capable of scaling a business process needs to contain links between centralised work planning and distributed work effects. Such links assure process consistency as well as correct interpretation in all areas and levels. However, for this to work, the information flow between planning and effected areas has to be phased and segmented. At each phase the information is modified with regards to where it goes further. See also Information Enabled Workflow
As information can be phased or segmented during the process of scaling, it is important to realise that new information might be added on the way as well. The additions are often necessary or even desirable. Imagine a complex plan which is made scalable by means of divisions, work units, time frames and instructions. No one has the business intelligence and expertise for conceiving a plan without further requirements for additions.
As it is scaled, the plan goes from hand to hand and, at each stage, it is reduced, enlarged or anyhow modified. The chains of tasks that a plan usually contains are broken down to other sub and sub-sub tasks, each with its own little plan and execution tactics. Indeed, the process of plan additions and modifications should be coordinated. Therefore the scalable plan should contain not only scalable information but also the means and prerequisites of how it could be modified during the process of scaling and who could be allowed to do the modifications on the basis of what expertise and capacity.
Measures in Process Scalability
Scalability of a business process must be accompanied with measures that would determine the behaviour of process elements during scaling. These measures such as Stakeholders’ Interests, Legal Frame, Contractual Duties etc can be distributed by systemic means along a business process. The means are called Transitive Rights, Hereditary Templates and Work Stakeholders. See further Organisational Design
We define three major systemic means empowering desirable modifications within the process of scaling:
- Hereditary Templates
- Transitive Rights
- Work Stakeholders
Hereditary Templates are either constitutional (corporate, legal and organisational) setups or business process structures which have been created for a specific purpose and are scalable by transferring (‘inheriting’) from one place onto another either as a whole or in parts or sequences. Hereditary templates could be scaled as ‘codes of practice’ related to one or multiple business environments, carrying large management platforms e.g. industry standards as well as very specific instruction setups related to basic tasks.
Transitive Rights are areas and levels of access which enable some of the associated roles to amend modifications, reductions or extensions to delegated work. The rights can be transited from one stage onto another along the traditional chains of command as well as across, depending upon the temporary purpose for which they are applied. It is important to realise that the traditional corporate hierarchy is not always decisive in a project environment where some transitive rights can be subject to the requirements of a work process rather than to corporate procedures. The need of defining project-driven rules is even stronger within an environment of several corporate entities with varying individual interests working closely together. Their cultures might or might not be well compatible and their corporate procedures might conflict with some of the most essential and logical needs of the project.
Transitive Rights Application Model
Example of Transitive Rights Application Principles:
One of the Corporate Task stakeholders of Company A decides to create a Project out of his Task. He becomes the Leader of the new Project 1. Project 1contains several Tasks. One of the Tasks exceeds its scope and requires a creation of a new Project. A stakeholder of the mentioned Task becomes the Leader of the new Project 3.
Organisation A and B decide to collaborate in a Project. One of the Corporate Task Stakeholders of Organisation A is invited to participate in Project 2 which is created and led by one of the Corporate Task Stakeholders of Organisation B. By means of Transitive Rights, which are in Abillance.com distributed along delegated Tasks and Task Stakeholders, both organisations A & B can see all that happens in the shared section of Project 2 (as indicated by yellow colour). Graded colour shades in the graph indicate frames of access available to Task Stakeholders exactly according to their delegated authorities.
In a Project environment, whoever delegates, can see all that is done by whoever is delegated, including further delegations. In an Organisation environment, whoever is superior, can see all that is done by whoever is subordinate, including further subordinations and transfers to Project environments. This interlinked chain principle allows for fast, flexible and absolutely controllable scaling of business process.
Transitive rights can also reflect permissions to what category of information a person who is transferred the rights upon will be able to access. Such selective permissions usually affect:
- Who can see what
- Who can do what
- Who can delegate whom
- Who can decide what
- Who can change what
Selective Areas of Transitive Rights
Work Stakeholders are roles closely associated with structures and units of work. There are three decisive roles in a traditional project environment:
Assigner is the one who delegates a project (or its part) upon a physical or corporate entity. Guarantor is the one who approves a project’s accomplishment and generally supervises important technical and operational standards. Executor is the one who practically does the work. All three can either be corporate or physical entities depending upon the nature and size of a project. As for the systemic environment, which is to empower phased and segmented information scalability, size does not really matter; we consider the three roles to be always bound to a universal and scalable unit of work: a Task. A task can represent a whole project as well a small piece of purpose-driven activity. In both cases, the roles that have been given the authority & responsibility over a Task become task stakeholders.
Understandably, if a Task represents a whole project its stakeholders would be different from those engaged in a simple operational Task. Though, their impacts upon the Task’s assignment, approval, and execution would in principle be the same. By means of engaging various identities of Task stakeholders we can project and secure often fine balance between individual, project and multi-corporate interests. (See further organisational design.)
Hereditary Templates, Transitive Rights and Work Stakeholders are scalable vertically across management levels or horizontally across departments and corporate boundaries, or in time - from one stage of a process onto another. They can be released to many places at once or scaled sequentially only to one place at a time. Possibilities are many and each solution is unique and different. It is imperative not to forget that their only purpose is to empower scalable impacts of distributed work.