Documents are fundamentally a semi-structured way to convey an idea, mostly with words and pictures. This inherent flexibility generally produces documents of low value due to tight time constraints. They are a great idea at the time, put together quickly to serve their immediate purpose but ultimately doomed to gather electronic dust. This is why most BW document libraries are large, cumbersome and not that helpful.
A documents life expectancy increases significantly when it gets the time and attention to align it with the goal of the reading audience. The more ‘fit for purpose’ the document is; the more structured, more focused, more cleaner and longer it will live.
Process documents and application documents are two types that align with readers goals to achieve results that build into outcomes. They are practical and used by beginners, experts and everyone in between. [Except Tribbles; they are too busy doing you know what to read].
For Example:
- Process Library: How to Configure the SAP GUI and Add-ons;
- Application Library: How to Install the SAP GUI and Add-ons.
For Example:
- Process Library: How to Setup the Desktop Printer (BLDG-C-FLR-3-PRNT-3-COLOUR);
- Application Library: How to Print to Your Desktop Printer (SAP LOCL).
For Example:
- Process Library: How to Request a Service Market Place (SMP) Account and Developer Key;
- Application Library: How to Create a New Service Market (SMP) Account;
- Application Library: How to Request a Developer Key from Service Market Place (SMP).
Can you see that the topics might look like they overlap so much that your already thinking they should really be a single document?
Now take a look at the information that goes into each one when you consider ‘who’ will actually be using the document and ‘where’ that document will live. This distinction of ‘who’ and ‘where’ is what guides you to choose:
- Is this a process or application document?
- Should this be split into two documents?
A process document usually covers a mixture of people, teams, systems and activities at a high level of understanding. The bigger picture. The overall sequence from start to finish. Less detail.
An application document usually has a narrow focus on achieving one result that is part of a larger outcome. It covers all steps required to get the work done. The full detail. The ‘How to Request an Service Market Place (SMP) Account and Developer Key’ is targeted at BW Support and BW Developer team members. It outlines this enterprises expectations on who can request one, how to request it and how to conform to the approval process. It is very specific to this enterprises process work flow. It can contain contact details, email addresses, security exceptions and even prerequisite guidelines that must be read & signed before approval is given.
The ‘How to Create a New Service Market (SMP) Account’ is a generic step-by-step document used by the enterprises personnel to navigate the SMP application and achieve the desired result. It is very generic to the application and independent from any enterprises process. It does not contain any user specific logon information, only where to go to do it.
The ‘How to Request a Developer Key from Service Market Place (SMP)’ is a generic step-by-step document used by the enterprises personnel to navigate the SMP application and achieve the desired result. It is very generic to the application and independent from any enterprise process.
For Example:
- Process Library: How to Setup the Portal Logon Links in your Web Browser;
- Application Library: How to Find the Portal Logon Link.
The ‘How to Setup the Portal Logon Links in your Web Browser’ document is specific to the enterprise reporting environment. It will guide the reader to where the list of systems is available from and also to other related documents needed to complete this process. This document is used by business reporting users, the basis team, the BW team and even project managers.
The ‘How to Find the Portal Logon Link’ is a generic step-by-step document that shows you how to dig into the backend configuration of a BW system and get the public url that is the official web reporting logon link. It would be used by BW and Basis team members as the business reporting user community probably does not have the confidence or system access to find it. It is very generic to the application and independent from any enterprise process.
Looking at the two portal documents, can you see that the list of ‘who would use the document’ is not the same. This provides an opportunity for productivity improvement as the work done by one team can be leveraged by another. In this case, the BW and Basis teams are capable of doing the ‘How to Find the Portal Logon Link’ work and storing the result in an appropriate place for other teams.
Most enterprises will do this for the business reporting users by putting a favourite or bookmark in all web browsers that points to the reporting logon page for the production system. The application support team will roll this out easily, using the same process for all the other software used by the enterprise on their standard desktop configurations.
Unfortunately, this is usually where the leverage between teams stops. The BW Support, BW Developer, project manager and business reporting users who get involved in User Acceptance Testing (UAT) will get left out in the cold and have to waste precious time (which is money) setting up their own favourite or bookmark for the non-production systems.
This is where the ‘How to Setup the Portal Logon Links in your Web Browser’ document from the process library really saves you time and money. Anyone who now requires access to the non-production systems can efficiently set it up themselves. People do not run around complaining about not having this information or not understanding what should be done, etc. It eliminates a lot of excuses, reduces question time and ensures everyone is working on the same systems, using the same configuration and moving in the same general direction. [Hopefully].
“prioritise document creation by focusing on
‘who’ will use it and ‘where’ will it live”
Creating documents for the sake of covering all topics is just a waste of time. The documents that need to be created for my BW Document Library will present themselves to you, through out the month. All you need to do is pay attention to the questions people are asking you. When a topic keeps appearing then move it up the priority list. Only document the top priority, one at a time and wait a while for the priority list to re-arrange itself according to the questions from others.
To put this into perspective; an enterprise that only does support / break fix activities and has very little project work going on will not really need a ‘How to Setup the Portal Logon Links in your Web Browser’ because the few people who do the UAT would already have it setup. In any given year, you would be lucky if 2 or 3 new people needed the links setup.
On the other side; enterprises that constantly deal with revolving customers, employees, consultants, managers and developers on a regular basis, would save a lot of time and money. By supplying them with appropriate process library documents they become self-sufficient while mitigating the risk of incorrect configuration and increasing an understanding of expectations the enterprise has on them.
It does not matter what role is performed within the team; we are constantly being exposed to the questions that drive the prioritisation.
What document would provide me the most benefit, next?