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!