The documentation of business applications in enterprise is often a tedious activity requiring rigour and tenacity. Often regarded as important but not a priority, it inevitably becomes obsolete over time and projects.
It is usually the same on the ServiceNow projects. Once the platform keys are entrusted by the integrator to the client, the first drifts settle. The impacts of non-up-to-date documentation are felt during organizational change (1), a reversibility period of OLS, or in the presence of malfunctions on critical applications requiring expert intervention, often external.
The documentation considered anecdotal at a time of the project, then becomes indispensable to better understand the level of personalization of the proceeding to improve/correct the situation and regain control.
Finding a solution to ensure the continuity of exploitation and the resumption of the ServiceNow platform is a major constraint to which the administrators of the platform must cope (turn over internal/external) (2).
Today, the feedback on any project ServiceNow in “activity” leads us to the following conclusion: technical documentation is a pre-requisite for anyone wanting to measure the degree of personalization of an instance and avoid any regression of setting up. This recurring charge is estimated at 2-3 days per month for a FTE on medium-sized projects (3).
It is necessary to rethink the form and use of the documentation. In the face of these findings, why not consider redefining the concept of documentation or how to build and maintain it?
This is precisely what Atlantic Puffin brings the answer to. The “dokument” application allows you to think “information and knowledge” rather than document.
A document is only a container. The important thing remains the content! Regardless of whether it is broadcast in an office format, an e-mail, fields of stories. What is ultimately important is the lifecycle of the developed functionality but also to know what it serves, to whom it serves and when? The purpose is to rapidly obtain cases of use of this documentation. I think this is a bit superfluous and needlessly lengthens the text.
Thus, the value of the application made by Atlantic Puffin lies in the fact that each setting, every customization of scripts, every writing of stories, every incident or request for evolution can be linked to an object “tuning”. The latter, coupled with a setup batch, will be equipped with a version number and will contain the technical description of the set up (4).
(1)The departure of key people from the admin team also becomes an opportunity to make the point on the existing via a technical audit or a retro-documentation. Difficult then to dive quickly in several weeks or months of settings.
(2) Transfer, change of integrator, redemption/merger of companies etc.
(3) ITSM subscription + 1 trade with 100 fulfiller users
(4) It is then possible to get rid of the “paper” documentation describing an architecture, to assist in the implementation of applications (shifting between teams, integrator changes, etc.), to participate in the maintenance in operational condition of key applications etc.