Supporter and enabler, not driver. But with cloud & low-code apps they often become innocent bystanders
IT supplies the infrastructure hardware security and the links into the legacy to be used by the new outside in systems driven by BPM principles. IT is not required to build this next generation set of applications. Build is direct with users and their input in their language. The leader in build will be business focused well within business analyst skill set.
Processes & systems go hand in hand. Parts of process execution (handling the cases) is automated and the choice of IT automation will impact the execution in a positive or constrained way.
In today's world you can't imagine how processes are executed without IT, but it starts with really knowing the process and being clear in what you want to automate...(operated in another way).
What Role should IT play in BPM?
Depends on the corporate culture/organizational structure.
In a project-oriented organization (e.g. heavy construction), operations are pretty much independent but need to look to HQ IT for guidance in the selection of operational software (e.g. CPM, estimating, cost control, financial apps).
Reason: Staff are frequently transferred from one project (locally, domestically, internationally) to another and it would be very disruptive to have different sets of functionality in use.
In large decentralized organizations you find highly independent business units that do not relate to top-down mandated choices re operational tools.
Within hierarchical operations at a particular business entity, IT should be involved in selection of the tools that different functional units work with, particularly when processes span units.
Here the choices seem to be to have a BA Unit, possibly within IT, but not necessarily. The BA unit can take on "roving" responsibility for process development/improvement, IT can provide BPMs support. In the absence of a BA unit, IT has to step in.
If the culture supports individual units building, owning and maintaining their own processes, we quickly get to a discussion on "low code" and IT typically needs to attend to rule-set building/maintenance and bridging processes across silos. Silo dwellers may be able to build, own and manage their own processes but rule-set building is typically beyond their capabilities.
The problem with the "look ma, no hands" approach arises when some units are unable to "think" process, or never get around to it. The remedy is, again, IT, or outside consultants.
OK, IT should "enable" BPM. But what does this mean?
It means that IT's role should be to enable business people to do BPM without IT.
But more specifically this means implementing the strict segregation of IT infrastructure interface contracts per Volker's Stiehl's recipe. When this is done, then business people can truly begin to realize the promise of BPM:
Of course the definition of "IT" itself is changing, and has already done so, such that IT is more about orchestration of information management services, many or most of which are outsourced, than it is about application development or even operations.
I get a sense though that this current state of affairs is not always reflected in our BPM conversations. To promote BPM is to figure out first who the customer is and separately who is responsible for that enabling infrastructure. To assume a traditional IT governance is miss the opportunity to sell the technology of "the language of business" to the business people who really need it.
From the enterprise point of view, an IT department is the “most” enterprise-wide function because other supporting functions has lesser impact on the enterprise functioning.
Considering that a typical business unit is a functional silo and typical BPM consultants are targeting “quick wins” (often quick and silo-like solutions) then ONLY the IT department may prevent a mushroom-like usage of BPM within an enterprise.
1. enable bi-modal IT: (traditional: open up systems of record; new: create experimental framework and get out of the way)
2. secure redundancy of internet connectivity :-)
Two roles for IT come to mind, depending on what you mean by IT.
IT as internal software service provider
The traditional view of IT is as an internal function that provides software services within an organisation, using some combination of software products and in-house software development. Traditional IT’s role in BPM is simply to make software tools available that enable BPM. You’d be forgiven for thinking that this kind of IT’s role in BPM is to waste most of the available budget.
One particular problem with this model of IT is that it assumes that IT provides the software service, which makes it blind to Software as a Service solutions that business operations can buy directly.
IT as technology experts
In theory, you don't need any IT systems to do BPM, and the only technology you need are pens, whiteboards, flip-charts, sticky notes and the like. However, in practice, these tend to make a mess of your office and so people start using software, even if only Microsoft Excel.
A broader view of IT sees its role as technology experts, which includes understanding all of the options for providing software support for BPM, whoever provides them. These days there are probably more BPM software categories than their used to be products, which means that choosing an appropriate solution requires expertise all of its own.
If IT merely asked ‘the business’ what it wanted, they’d just ask for the BPM equivalent of ‘faster horses’*, which is how enterprise IT ends up spending twice the planned budget to roll out a bloated solution in an IT project that is probably going to fail.
The role of IT - it the broader sense of the IT industry - is to invent killer software applications that make it possible for BPM to become a mainstream business activity, in the same way that the first spreadsheet was the killer application that turned financial modelling from an obscure niche into a mainstreambusiness activity.
* which Henry Ford probably never said