The many processes that run the many services of eGovernment — DigitalState.io

Online government services are bundles on business processes that run the bureaucracy, and government software developers should think process and platform rather than “apps”

Government services are driven by business processes, and it is these processes that individuals, businesses, residents, and tourists (all of who we will refer to as citizens) interact with when contacting a government. In the government back-office, staff interact with the same business processes to fulfill the requests made by citizens. Governments offer a very large number of services and even larger number of business processes are used to fulfill the requests for those services. With shrinking budgets and resources available to digitize existing services, and no resources or budgets to build new services, how can government IT departments and government business units offer services at scale with existing resources and operational budgets? At DigitalState we talk about scale in governments Digital Public Services in terms of horizontally and vertically scaling: horizontal scaling is offering additional services, and vertical scaling is a service being able to handle additional requests.

In a small local government, there are at least hundreds of services, and each service can have multiple processes. Look at a government such a Toronto, New York, California, or any national government, and you find the number of services and supporting business processes can increase exponentially.

Governments are really just a a bundle of different business units. The private sector equivalent would be a number of subsidiaries under a parent company. The difference is that governments tend to bundle all of the subsidiaries/business units into a single organization. This is especially true at the local level of government:

police, fire, paramedics, public health, public works, transit, parks and recreation, sanitation, environmental services, tourism, social services, security, infrastructure, etc.

Each of these business units have their own staff which have their own priorities, policies, and business processes to fulfill the services they are mandated to provide.

Lets look at one of the most common in local government across North America: the Animal License/Pet License. Depending on the location, a local government can have many variations of the licensing of a ‘household’ pet (cats, dogs, exotic animals, etc). For this example lets look at a Dog, and the service to License a Dog:

Dog Licensing

It is easy to understand the government service, Dog License:

1. Fill out a form.
2. Sometimes pay a fee (depending on the rules).
3. Receive a dog license.
4. Receive a ‘dog tag’ which you attach to the collar of the dog. The tag signifying you have a license for the dog.
5. Renew the license on a recurring basis depending on the local laws and policies (usually once a year).

Seems pretty simple, and if we were to ask a government IT department to build this, they would start a IT project to build the “Dog Licensing App”, which would contain everything needed based on the business and technical requirements that are so carefully negotiated between business and IT.

The simplest implementation of this service (and is commonly implemented this way) is as follows:

1. Fill out a form with your personal information and dog’s information.
2. Determine if you must pay a fee. If yes, calculate the amount based on the pricing table.
3. Submit the form and if applicable, make a payment.
4. The form is processed by government staff, and either approved or denied.
5. If the license is approved, the government staff create and issue the dog license and dog tag.
6. Renew the license as required.

Steps 1, 2, and 3 would be put into a small web application or web form, and steps 4, 5, and 6 would be some sort of task list or just an email with the submission information sent to the back-office. Staff would manually process the request using something like Excel, paper, or maybe some sort of database driven application.

The problem with this scenario is, it only solves one part of one problem (providing the citizen a digital experience), rather than transforming the entire service: front to back, start to finish. The quality of the citizen’s experience may increase, but the overall process would remain the same, and scaling vertically or horizontally is not addressed (you may be able to receive more requests from a online web-form, but staff would not be able to “process” them any faster. Staff would still be using policy binders, checklists, and memorized procedures to process the requests. The processing (which is arguably the most time consuming and expensive part of providing the service), remains manual and lacks digital transformation. At DigitalState, we think if you are going to build online services, you should be looking at the whole picture, front-to-back, start-to-finish, and have the platform in place to handle service transformation at scale. This does not mean you must transform the all services or even a single entire service all at once. But we do believe that it is critically important that governments have core in place enabling business units to incrementally transform their business practices and as a result transform their services.

The Licensing Processes

Look at the typical processes that are involved in dog licensing:

On the citizen experience side we see five business processes:

1. New Dog License Registration
2. Replacement of Lost Dog Tag
3. Renew Dog License
4. Change Dog Details and Status
5. Change Dog Owner’s Personal Details

These five processes are how and when a dog owner/citizen would be contacting the government through the supported channels for dog licensing. For governments that use DigitalState, this would be the Online MyAccount or 311 channel. But it could be in-person, by mail, or fax depending on the governments selection of supported channels.

In the back-office experience we see six processes:

1. Process and Issue Dog License
2. Process Dog Tag Replacement Request
3. Issue Renewal Dog Tag
4. Notify Need for License Renewal
5. Notify of License Expiry
6. Issue Dog Tag

These six processes are how the government fulfills the requests made by the citizen in the citizen experience.

The Back-Office

The majority of the back-office processes will have activities where staff (or third-parties such as pet stores and contractors):

1. Review documents
2. Approve or deny requests
3. Escalate to Tier 2 staff or management for review, comment, and approval decisions
4. Interact with elected officials for input, feedback and possible approval requirements
5. Require approval by Tier 2 or management before executing an activity
6. Call/email/notify staff, citizens, and third-parties about the start, current state/progress, and end of a process or activity

The processes and the activities are important to governments because, like most enterprises, the organization runs on a bureaucracy, which operates using repeatable and stable business processes, backed by Policy and Standard Operating Procedures (SOP). As much as Startups push for government to be agile and flexible, we must remember:

Government is designed for stability not agility.

This does not mean you cannot bring agile practices into government, but providing service stability, regardless of the staff providing the service to the citizen, is very important to governments and their service delivery standards. With dog licensing it may not seem like a significant concern, but imagine you were applying for a grant, social services, un-employment assistance, or any service critical to your personal or family’s welfare: you would expect at least the same level of service as everyone else, and that the quality of the service was the same regardless of when or where you were accessing it. This is why governments traditionally think in terms of robust, stable, and repeatable business processes.

Transforming to Digital Public Services: Apps to Platform

If we want more government services to be fully available online, across more channels, reduce costs and reduce time to deliver those services, the business processes that drive government must considered. Building apps is great, until you are the IT department that has to manage thousands of small and large apps with your “5 person team”. Not only is your team responsible for the maintenance of all of the existing apps, but you also have to build the new “apps” on top of your current workload. This is the reason why we caution when we hear of governments using or looking to use, Rapid Application Development tools (RADs). On the surface RADs seem great for government’s needs. But governments end up with hundreds or thousands of “apps” that need to be maintained, upgraded, and versioned through the the software development cycle. Even using agile, the IT department is not going to be able to provide every service the ability to be agile. Departments/Business units end up being lucky if IT can work on their service for a few days per year.

Instead, we need to think about things in the lens of a platform: Government as a Platform (The UK government created a great video explaining some of the core concepts). A platform where services are managed as business processes that interact with various systems. Government’s have ever-changing processes that involve inputs, outputs, approvals, handoffs, escalations, service level tracking, status updates, related requests and associated documents and information. Government as a Platform should handle these tasks across all services and processes, and business need only worry about their individual business processes and the experiences/forms that citizens and staff interact with. IT Departments should worry about the underlying technological-services that enable business units to manage their business processes and forms, rather than having to worry about “apps”.

To move government services to digital channels using the platform approach, tied with business processes, developers and analysts need to remember that the majority of any government process is managed as Standard Operating Procedure (SOP) and Policy. Transforming a service to Digital should mean transforming the paper and human understanding of SOP and policies into digital representations, which means building digital business processes.

With Dog Licensing, a common example is the location where the dog will live. Depending on the location, a owner may be restricted to a limited number of dogs. This would typically be determined by staff when a citizen submits the request for a dog license. The staff would look up the address and base their decision on policy and act based on the SOP; or another way to look at it: the human interprets the policy and makes a decision. But when we move this service to digital/online, and want to reduce the costs of activities like determine the limit on number of dogs, we need automate, which means digitization of process. In order to automate, we have to find repeatable ways to transfer the policies and SOP into digital formats that business analysts can understand and maintain. At DigitalState we use our MyAccount, and Camunda’s BPMN and DMN engines.

Re-ordering of the “steps”, adding or removing business logic, approvals, escalations, and business error handling are very common, and should not require systems to be re-built, re-architected, or have IT negotiate down which processes and what parts of each process will be “coded” into the app. This is why DigitalState is so focused on the conversation of “business processes” that run governments’ digital public services. Using business process and more specifically BPMN and DMN, allows the business units to model the process they want to follow (regardless of how simple, complex, short, or long, or how efficient or bureaucratic it may be). The BPMN and DMN engines will execute the process and business logic however the government business unit choses to operate. This gives every business unit ample opportunity to transform on their schedule without dependencies on IT departments or competing capital-budget or operational initiatives: where you model the existing process, and make incremental improvements (even in a agile way). The processes become part of the platform. The platform is a makeup of the components that run government services, and SOP, policies, and the information that would traditionally interpreted by humans/staff, can be managed in a fully or semi-automated process.

If future posts, we will be exploring the dog licensing service further as part of a platform and and breakdown the common activities found in the business processes that run the service and governments in general.

If you are a government employee that runs online government services, or looking to move your services online, let’s compare notes and stories!