Tradition in government, perhaps more than in any other industry, often plays a substantial role in carrying out the day-to-day activities of the organization. Legacy methods and processes that were developed at the start of a particular program, grant, or department are seemingly etched in stone. And in fact, some were created by a legislative body with the intent that they would not be easy to change.
However, there are sets and subsets of workflow rules that seem to endure from sheer inertia. I call it the "because we have always done it this way" phenomenon. I am sure you have encountered the same thing many times in your career in government. Often, it is shrugged off as bureaucratic red tape that has to be dealt with. Because of this, we often work in organizations that are slow and unresponsive to the needs of its customers—which, in the case of government, is the public. This slowness and unresponsiveness is, unfortunately, part of our reputation as government employees.
So whose responsibility is it to make the organization more nimble and agile, to be able to shape our government organization into an "on-demand" entity? Ultimately, the responsibility for changing the status quo is management's. However, IT does have its own important role to play, and it's not just through the employment of technology. We can be the carrot, the stick, or both when it comes to encouraging a hard look at how the departments we serve do their work.
I'm one of those people who believes that IT should be involved in helping the rest of the organization do its work better because it's our job and that IT shouldn't just be looking out for its own narrow interests. But there is also a selfish reason for having this perspective. IT people know how much easier it is to create, implement, and maintain systems for those departments that really understand their business processes.
How to introduce Business Process Mapping
How can IT participate in increasing the efficiency of the departments it serves? One way is to introduce Business Process Mapping (BPM) to the organization. Process mapping, a fundamental component of Business Process Management is the practice of creating visual aids for processes/workflows showing inputs, outputs, and tasks and how they are related to one another. (For the purposes of this article, BPM will refer specifically to mapping.) There isn't a single methodology for launching BPM, or one software package for creating it. Almost all the major software vendors have a method or package they promote (Oracle, IBM, SAP), and there are tons of BPM vendors specializing in this area (TIBCO, APPIAN, Pegasystems, to name a few) so you should not have a problem finding information on how to get started.
More important than the specifics of the methodology or software used, is how you introduce BPM to the organization and respond to the roadblocks you may encounter when doing so.
Some will argue that the best method of introducing BPM is to do so in tandem with an IT project in a business area. Another way of introducing BPM, independent of a particular software project, is to tie it to disaster recovery- or contingency-planning. While I don't disagree that these are ideal ways to do it, I actually want to promote the idea of BPM for its own sake.
Earlier, I talked about the carrot-and-stick approach to convincing organizations or its units to participate in BPM. One idea for the carrot approach is to make BPM a part of the decision-making process for IT project requests from other departments: for example, specifying that all departments which have a current business process map will get preference, enhancing their chances of getting a green light or the proper funding. Something like this can motivate departments to invite IT in to help them get started on the process or partner with them to complete BPM.
Conversely, you and your IT governance body (if you have one) could decide that no application development project can begin without a current BPM in place for the requesting department or unit. Without BPM, funding could be held up or project approval would be harder to get. (This is the stick approach).
Outline the benefits of Business Process Mapping
In order to convince departments that they should create process maps, you need to be able to identify the benefits of doing so for them. Here are a few:
- The exercise of examining your work often allows you to gain a greater understanding of the tasks and problems that are faced within the organization. This gets back to the "because we have always done it this way" phenomenon. Practicing BPM and keeping it current helps to eliminate this kind of thinking.
- BPM allows you to re-engineer your processes as you discover inefficiencies.
- Keeping BPM current allows an organization to respond more quickly to its customers; if you are familiar with your processes, you can quickly see how changes will affect those processes.
- Business process transparency is good both for workers (who can clearly understand the business) and the customer (who often demands transparency in the case of government operations).
- IT can be more responsive to the business unit, creating applications and systems where business rules are clearly understood, making it possible to make changes without adversely affecting existing applications and cutting down on the creation of new code. This takes advantage of service-oriented architecture (SOA) and event-driven infrastructure models.
- It is easier to manage an environment that is well understood.
- It aids in regulatory compliance.
Lastly, even though BPM is in an organization's best interests, regarding functionality, there can be great resistance to it for a number of reasons:
- Some departments are not interested in exposing themselves to the spotlight of BPM, possibly opening them to criticism.
- Others are just plain scared of change or doing something new.
- Departments don't want IT to "tell them how to do their work"—which is why it is very important to make sure you try to make BPM a partnership.
In any case, BPM should be an initiative you roll out as part of IT services and one that it can offer independent of particular technological solutions.
Keep up with the issues and challenges that uniquely affect public-sector IT with TechRepublic's free Government IT newsletter, delivered each Tuesday. Automatically sign up today!