As discussed in a future book , a different approach on the definition of the market positioning of your organization will be needed.
“Organization”, not “company”, as local authorities and countries alike lose/gain through this additional transparency, and, with the extension of subsidiarity, they too will need to find ways to attract investment (and tax-paying corporations).
After this extended assessment and evaluation of its qualitative effects, introducing e-government, like any other project, should be assessed for its quantitative cost.
Obviously, with “normal” projects you have at least the theoretical option of cancelling the project, an option that is not available with e-government.
In 2013, e-government has been confirmed to be more intrusive than it was expected, also if the regulatory framework is still a work-in-progress.
The options you should first identify are:
- to what extent should e-government be introduced inside your organization
- by when you should roll-out each new requirement
- is there any flexibility, and for how long
- could the e-government-related changes be kept aside from the company, or should be embedded in business processes
- how can you compartmentalize information to avoid disclosing sensitive business information
The minimal cost categories to consider are:
- compliance: is the direct cost of producing the information required
- infrastructure: is the cost associated to storing and processing the information, along with any new infrastructure cost (e.g. paying a monthly fee, or buying digital certificate)
- delivery: is not only the cost to deliver, but also to manage the delivery process (e.g. storing the feed-back, re-sending, managing the production of updated information)
- maintenance: is the cost to support the previous three.
Let’s see an example: electronic filing of payroll information.
Law requires delivering a certain amount of information with a stated frequency and keeping track for a certain timespan.
Assessing costs should be quite easy in this case, as it is just a normal project to produce and deliver some files, but once you introduce transparency and ICT as a communication medium with government agencies, consider that they could make some assumptions on how your company works to produce that information.
A customer in Continental Europe reported some twenty years ago that they were requested statistics on payroll from the government agency collecting the monthly information; problem: the statistics’ contents extended beyond the statutory time limits; legally, the government agency could not require the old data, but legally, there was not statute of limitation on the statistics.
Once they delivered the payroll statistics, the government agency called back and said: “as obviously you have the underlying information, could you deliver that information as well?”.
The reason? A technical and organizational glitch resulted in losing and/or misplacing data tapes, and somebody at the government agency came out with a creative way to solve the problem.
In the future, constantly increasing transparency could result in further integration, and therefore when costing the introduction of e-government consider all the side-effects of related regulations, not each item separately.
Also, e-government makes more sense for the government if, once assumed that certain processes are carried out inside the information providers (the companies) and work properly, a certain degree of redundancy is removed by consolidating services, and maybe the government agencies focus on becoming just the “knowledge manager” for the specific set of rules, outsourcing all the data processing to a central unit that, also for privacy/security/etc. reasons, will have no clue about the data they process.
As in other projects, the longer the time some resources go unused, the easier is that they come to be considered “redundant” .
More so if on the receiving end you have not one organization that knows the meaning of the information that it is processing, but some low-cost, centralized unit, whose internal budget allocation will be linked to further constraints, and that will make decisions on the basis of the internal knowledge available (documentation, etc.).
When introducing e-government processes you have to take further precautionary steps while defining the SLAs (Service Level Agreements), because e-government is, in the end, something whose evolution is outside your control, but the deeper it affects your own internal business processes, the greater the loss of flexibility in your managing the evolution of your own organization.
Overall, the suggestion is: outsourcing requires assessing both the financial savings and the impact on business continuity.