Does your organization have more than four departments? Is it more than five years old? Have most of your mid-level...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
managers been on the job for much of that time? Then I'll wager that the business process automation systems that power their departments rarely, if ever, cross organizational boundaries. This is an operational shame because it slashes the value these systems bring to the table. The good news is that organizations can readily break down silos using tools that are already in place.
It's not you, it's me
Organizations typically begin with a structure built around a relative handful of individuals with specific and separate responsibilities, and grow outward from there. In the early days, processes flow freely as the principals seek each other out to complete tasks or resolve issues. But as the workload increases, staff and technology are added to handle it. Such interactions become less frequent and more forced and the groups become increasingly less collaborative. Over time, they become independent silos unto themselves, and even end up investing in their own computing processes to optimize their efficiency.
Inside the silos, nothing about this seems illogical in thinking that "No one else does what we do, so why shouldn't we do our own thing?" But organizationally, it results in the proliferation of disconnected processes and infrastructure supports, and the propagation of a standalone culture that makes it nearly impossible to achieve efficacy and economy on an enterprise scale.
As examples, take note of three situations I've been close to over the past several months. The organizations in question are in very different industries (two highly regulated, one not), and are very different in terms of geography covered and scope of operations. And yet, records and compliance officers in all three are yanking out their hair as they try to find, access, retrieve and compile materials from all departments to meet their audit requirements and deadlines. If only, they cry, some kind of technology could automate these queries across the whole organization.
Let's pick up where we left off
Such a technology does exist in the form of BPM and workflow, two capabilities being lumped together because they are so closely related. The key to using this technology successfully is to understand that, in most instances, the end of one process actually kicks off another, which picks up where the first leaves off. So there is a macro-level view that must be adopted if a to create a more unified approach.
For example, when a department buys a new software package, it triggers an accounting event to pay for it and an entry in the license management database to ensure compliance with the vendor's terms. Or at least it should, even in the most independent-minded groups.
The problem is that, in a siloed situation, there may be no automated way for the department manager to obtain the required purchase order (if they request one at all). More than likely, a phone call is made to accounting and no one thinks about updating the equally unconnected licensing system at all.
Solving process problems like this is pretty much why BPM was invented, and when approached from the enterprise perspective, getting the job done is relatively straightforward. But what is an organization to do when the all-but-isolated technology doesn't -- or can't -- talk to each other?
I never metadata I didn't like
Traditional techniques would have you spend time and money to programmatically integrate the various systems so they can talk to one another. Unfortunately, many (especially legacy) applications aren't built to accommodate this or require some seriously heavy lifting to crack them open.
Here's the good news: Nearly every system includes some degree of metadata support and BPM can use the metadata to move processes forward. In my software acquisition example, the licensing system might be charged with monitoring the accounting application for a state change that indicates a purchase order was created, and then read the "vendor" field to see if the name appearing there is that of a company it knows to be a software provider. When it registers a hit, it might then send an email to the department manager for details, thereby completing the process loop across multiple business units.
Is this a bit clunky? Sure it is, and most modern approaches allow for something a whole lot more elegant. The point is using metadata works even if BPM exists in only place in the company.
Start me up
This last point reminds me of perhaps the most important thought I can leave you with: If you meet the profile outlined at the top of this article, then chances are you already have BPM somewhere in your organization. This is great news because it means you can start breaking your silos down (probably) without having to invest in any new technology.
To do this, though, you have to turn your BPM on, something that one of my three friends unaccountably has chosen not to do. My guess is that the capability came along with an application that a department purchased for some other reason, and no one even thought about using it -- never mind extending it beyond the bounds of the department that acquired it.
So if your operation is siloed, then I'd encourage you to start looking for ways to use BPM and metadata to get your organization to work as a unified whole. It's a great way to maximize the total value of the software you already have in place -- and your compliance people, perhaps first among others, will love you for it.
Steve Weissman has a 20-year track record of innovation and success in information governance and process improvement. Principal Consultant at Holly Group, he uses a proven proprietary methodology to optimize clients’ approach to basic planning, vendor selection, user adoption, and everything in between, ultimately positioning them to derive Maximum Total Value from their information and their information technology. He can be reached at email@example.com or 617-383-4655.
Architect's guide to BPM workflow
Breaking silos with big data adoption
How can BPM support robotic process automation?