Storyboard Folder MGMT Visions

1
SAP Folder Management A White Paper
SAP Folder Mgmt Visions and Ideas

Preamble
This document is a work-study and a result of work performed for international clients over many years. It is a vision and ideas list, rather than a product definition (which it could be). The writers do leave it up to the makers of this software product to follow their strategies. Eworks Consultants Co. Ltd. is an independent organization, supplying consultancy to major clients of SAP AGs clients. Consider us scientists or academics, rather than market leaders. Eworks point of view might be different to current markets. Find us engaging and delivering to our clients! Findings herein are published under the Creative Commons License and are considered to be a public view on softwares produced by SAP AG in Germany. However, proposals, ideas written in this document might be currently patented or/and if not will be patented in soon or made public under the Creative Commons License. Views shared in this document are again personal and might not be of public opinion. Again the above mentioned license adheres allowing us to present views and to publish our opinion, suggestions and thoughts. Portions of software, components, acronyms or paradigm mentioned in this writing are trademarked and/or copyrighted and/or patented by SAP AG in Germany. The writers acknowledge this fact in their quest to help evolve this vital software for their and SAPs clients. Portions of software, components, acronyms or paradigm mentioned in this writing are trademarked and/or copyrighted and/or patented by other parties. The writers acknowledge this fact recognizing these parties in their effort to build perfect solutions for their clients.
Intellectual Property copyrighted under the creative commons license EWorks Consultants 2011. All rights reserved. Visit us at: http://www.eworkscorp.net
Table of Contents
Preamble ................................................................................................................................................. 1 Preface..................................................................................................................................................... 3 Definitions ............................................................................................................................................... 3 Conclusion ........................................................................................................................................... 4 Effect ....................................................................................................................................................... 4 Findings ................................................................................................................................................... 5 Document Attributes ............................................................................................................................... 6 Conclusion ........................................................................................................................................... 6 Requirements .......................................................................................................................................... 7 Lock levels............................................................................................................................................ 7 Decoupling........................................................................................................................................... 7 Poid-Relations versus container linkage ............................................................................................. 7 PSRM and Parts ................................................................................................................................... 8 Record Models .................................................................................................................................... 8 Legos put together ................................................................................................................................. 8 Visualisation ........................................................................................................................................ 8 Poid Relations versus Business Object Relations ................................................................................ 9 Business objects in a record ................................................................................................................ 9 A 3d view-port ................................................................................................................................... 10 Terminology........................................................................................................................................... 11
Preface
SAP Folder Management evolved from once delivered by SAP in 2003, early adopted in 2005 by first clients to a full featured document management system within the SAP NetWeaver landscape. Being rich in features, tightly integrated into business applications, generic at the same time, it can provide for plenty of document management scenarios needed by organizations and enterprises. SAP Folder Management does address several requirements at the same time: Governance well documented business processes, that collect documents alongside business transactions Archiving as required by most countries regulations, long term storage of paper documents Life-Cycle Management a document might be starting a long term business process, another one ends it
SAP Folder Management does cater for short cycle business processes and long term documentation at the same time tying it closely to the relevant business objects at the same time.
Definitions
(This applies to any country, NGO or GO) {Citation from the NARS}
Records are the output of the business and administrative processes of a governmental body. In other words, the final proof that a business or administrative process was transacted. It serves as essential proof of the business that was conducted and should remain unaltered over time for as long as they are needed. As evidence of official business records have on-going use as a means of management, accountability, operational continuity, legal evidence and disaster recovery. They also form the memory of the institution that created them, and by extension, they are part of societys memory and the broader cultural heritage. In some cases records also have a bearing on the rights of citizens. A bodys ability to function efficiently and give account of its actions could be negatively affected if sound records management principles are not applied. The need for effective management of records is enhanced by the Public Finance Management Act, 1999, the Promotion of Access to Information Act, 2000, the Promotion of Administrative Justice Act, 2000, and the Electronic Communications and Transactions Act, 2000 in terms of which governmental bodies have an obligation to manage their records properly, to provide access to information contained in records, provide reasons for administrative decisions and to ensure the authenticity of records. Since one of the National Archives and Records Services objectives is to preserve public records with enduring value for use by the public and the state, the National Archives and Records Service is not only concerned with the management and accessibility of records over a short period of time. Records created in electronic and paper-based record keeping systems contain the memory of the decision-making of government and its impact. Intellectual Property copyrighted under the creative commons license EWorks Consultants 2011. All rights reserved. Visit us at: http://www.eworkscorp.net
The National Archives and Records Service has a responsibility to ensure that this memory is maintained and protected for centuries to come. To facilitate this the National Archives and Records Services role in terms of the National Archives and Records Service of South Africa Act, 1996 as amended is to promote efficient administration by regulating the records management practices of governmental bodies to ensure the sound management of the information resources. Records management is a process of ensuring the proper creation, maintenance, use and disposal of records to achieve efficient, transparent and accountable governance. In short, sound records management ensures that all the records that governmental bodies creates in the conduct of their official business are, and remain, authoritative and authentic. The impact of technology on official business and therefore on records management is not a new phenomenon. For example the introduction of the telegraph, typewriter and the telephone fundamentally altered the way business was done and records were kept. The advent of the computer altered record keeping even more. Computerised systems offer significant advantages over conventional manual methods. In particular, they can manipulate large amounts of information and generate a wide range of information products. Computers offer speed, precision, diversity, flexibility and a rich and comprehensive documentation of process, and it is no wonder that they have been so quickly embraced around the world as a critical information management and communication tool. However, the unique and fragile nature of electronic data demands a re-evaluation of the way governmental bodies manage records. Processes and procedures created to meet the needs of record keeping in the paper environment do not apply equally to electronic records. A reassessment of records management programmes is therefore required. In order to meet record keeping responsibilities, governmental bodies must ensure that electronic records are accessible and readable over time. An active programme committed to managing and preserving records from their creation to final disposal is a prerequisite of meeting these responsibilities. Any breakdown in the records management process increases the chance that electronic records that still have value to the body will become unreadable and inaccessible over time.
Conclusion
A document turns into a record(ing) of facts, once content and meta-data thus connection to relevant master data and transactional data is provided. Once provided, even without an ERP system available, a set of documents can prove the matter of content and context.
Effect
SAP Folder Management must cater for more than just providing a framework or shell to store documents. It has to provide for means of long term storage, easy acquisition of files, access control per file and means of organizing files in a well fashioned structure. Plenty of these features are currently hidden in SAP Folder Management, but not well utilized.
At the same time, when it comes to provisioning of documents, lets say for an auditor, information is not easy to grab. Reasons are: Documents might not carry the relevant attributes Document containers might not ensure attributes or access control such as o Records (in the favor of Records Management) o Cases (in the flavor of Case Management) o Folders/Parts (in the flavor of Public Sector Records Management)
As a result of investigations, it turns out that a major obstacle hinders SAP Folder Management to be really flexible and meeting legal and businesses demands: Document Containers got designed as XML files in times, when XML what the Web 2.0 roadmap. However it causes Document Containers to be locked on Container level, once opened in Change mode by users or back-ground processes. In effect: Once a container is opened by one process other processes, trying to do the same are STUCK! Single Documents as they exist for themselves are not affected operations on a document can be done Records, Cases, Folders do also serve as containers for business objects. Implications are that the link between a document/record/case or folder and its corresponding business object can only be located once parsing each XML document that does represent the container that can take hours, days, months - given the number of business objects or document containers. (Current SAP clients deal with TB of information and millions of documents!)
Findings
If the product would be database oriented, rather than making use of XML files for Records/Cases/Folders/Parts, result sets of searches would be more easily to achieve. Equally the navigation towards a particular document or set of documents could be improved by searching for them by the right set of attributes! This core feature is embedded in the attribute-set possible to documents, records, cases, folders and parts, but it is rarely made use of. At the same time, a rich set of attributes, that would synchronize with their relevant business objects at the time of query helps to Reveal results of current authority checks upon the business object on the various levels o By document o By record/case/folder or part Be independent of parent/child relations as possible, as children inherit most of their attributes from a parent Display result-sets independently of their parents architecture, meaning: o A result-set could be organized differently in comparison to a parents design (example given: Display in time-line, rather than by folder view which again is a feature of SAP Folder Management!) o Display result-sets in order of attribute combinations, example given:
Order by vendor first Then by document kind Then by document type Then by date of creation
Document Attributes
Introduced with PSRM in around 2006, the document attribute Document Type made the notion. How-ever, it depends on Element Type and thus usage to define it! A future structure could be: Element Type (thus RMS or usage, such as HR, MM, etc.) o Document Kind (thus another level of specification, such as Vendor Invoice, Employee income document, legal summons document) Document Type (another level sub to the Kind of Document, such as Vendor Invoice/Invoice Type, or Employee income/tax file)
International National Archives are currently trying to organize document structures, they are thinking in they view frames of Microsoft Windows Explorer and File Systems folders, but not thinking of what it would be if a document could contain attributes!
Conclusion
If document attributes would be defined, set and updated nicely, there would not be a need of folders as documents would be able to provide for their own structure of organization - thus a tree of view-ports from different perspectives. Again example given: From an IS-U or RE/XF point of view it matters, to whom AND WHERE contracts are made with From an HR point of view it matters, it purely matters to the question of whom and possible benefits made to that person
Another example given and again HR: Applicant versus Employee.. The layout of the documents required versus the documents provided might change
Lastly documents required vs. documents recorded is the main obstacle with records or cases! How to program software that would be able to find out, if documents are mission or answers to documents required? How to do this, if it would need parsing x-million of XML files? Every day business processes do clearly indicate that a request needs a follow-up response and usually there is a timing behind it. A legal summons wants a 7 days response; a purchase order might want a 20 days response. As a conclusion, documents should carry all the information necessary to continue, recover, reinstantiate a business case. Thus it is necessary to keep the relevant business process information within the meta-data of the document, which did cause the business case.
At the same time, view ports for different audiences need to be ensured! They should not rely on pre-defined record-models or folder-structures, they should rather enable a user to group by a set of attributes. A record-model for HR might fit the average HR user, but it does not fit for another user or: Document Management should be a flexible as business intelligence applications are, in order to fulfill the requirements of the auditor, providing for governance and train of thoughts in decision making (Baselx, ISP900x).
Requirements
Lock levels
SAP Folder Management (thus PSRM) has got the complication of not being able to allow massprocessing of inbound documents currently. Queuing solutions currently provided by SAP are weak. When taken into mass-delivery, current solutions and SAP proposed solutions fail, as they do not cater for record-locking, in the sense of: If one process opens a record/case/folder/path in chance mode, another process will be blocked. If it takes 10 min. to open the XML-File of a record/case/folder/path, this process is blocked. It would be an achievement, to only lock at the lowest level being the document.
Decoupling
At plenty of clients implemented, a de-coupling of processes truly helps! Meaning: Document information is loaded first, documents are being created. Lastly, information sorted well, documents are being inserted into their containers using queues and retry methods, in case the container is locked.
Poid-Relations versus container linkage

The information of which element is in which container is currently written twice! It is stored within the XML file of the record. At the same time it is written as a Poid-Linkage into the Poid Directory. This linkage is eventually being made use of for the Where-Used query, which every object offers. Considering this a Poid entry for an object is the true primary key to this object. A LOIO-ID of a document or record, or a case guid is only a secondary id. Poid relations do not only answer the question of Where-Used from child to parent(s), they also can answer the question of Contains what! Example given: To find out, which documents are contained in a record, a query into the poid relation directory would provide the appropriate result set. Since the poid directory is table driven, queries are much faster compared to opening and parsing one or many XML-files to obtain the same information. However, the query of contains what only returns the objects contained, but not the structure, sequence of or position within the container.
PSRM and Parts

Within PSRM the first attempt was made to take down locking to the lowest level within the hierarchical structure of a file plan. A folder (PSRM terminology actually it is a case) would contain a main record. This record would contain many sub-records, called part. Only one part or sub-record is open or in use at a time. Once filled to a certain level and XML parsing getting slow it would be closed and a fresh new part created. Interestingly, the structure of a part its record model is usually flat (or unstructured)! Parts do not have a further hierarchy defined within their record model. As discussed earlier: The poid directory is a fast way to answer the question of contains what, however without answering the question of position within the parent container. For parts in PSRM, the contains what query is sufficient, as the part is not further structured. In effect, a the service provider for the part could be a simple query mechanism into the poid directory displaying the result set ordered by certain attributes, such as creation date or element type (or other combinations of child attributes). Since the part currently is an XML file that needs to be parsed, the time it takes opening a part tends to increase with the number of contained children. Experience tells that parts should be closed once a number of around 500 elements are reached. With the current implementation of PSRM, this should be happening automatically, not manually.
Record Models
Record Models got invented to provide records or cases with a structured display layout. Again, record models belong to the family of document type service providers, as they do carry their information as an XML file. Once a record gets created, it will take a copy of the models XML file as a template for the display structure. Record Models are static once defined, all derived records will carry the same layout. In case business requirements do change records might still carry the old layout and not the desired new layout. Layout and Display This is in fact the only reasoning for record models! Again: If documents would carry enough attribute information and the poid directory would be used to identify the children of a record, layout and display could be provided on the fly or at runtime. If business requirements change or if different view-ports are needed within the organization, a record could have multiple models and display content differently depending on the requirement.
Legos put together

Records do serve as the lowest level container for documents within SAP Folder Management. The definition of their layout should be flexible and changeable, rather being considered variants of display than static models.
Visualisation
Records should have various models that provide for these variants of display which are tight to users roles different user role, different view port Intellectual Property copyrighted under the creative commons license EWorks Consultants 2011. All rights reserved. Visit us at: http://www.eworkscorp.net
Usually the record model does repeat (or duplicate) information, which is already known such as grouping of attributes example given (again HR as a sample): A section of a record contains the documents of kind income, type salary whilst another section might contain documents of kind leave, type sick-leave or vacation
Upon building the visualization of the record, The poid directory should be the source of information, of what is contained in the record Depending on the users role, a model or display variant would serve to arrange documents by their attributes Whilst building the structured display, each object is checked for its individual security or ACLs to eventually hide documents, that are not allowed for display to the specific user
Poid Relations versus Business Object Relations

(or taking apart what does not belong together) The true advantage of SAP Folder Management compared to other document management systems is its tight integration of document and business process transaction! The question however is: Where does this information need to go? Poid relations do indicate what is contained in a container (or: which documents are contained in which record). However a similar question using the current design of an instance of element type business object contained within an XML-file of a record would be hard to answer! It would take to open all existing records, parsing them, only to find out, that one only does provide for the link to a business object. Business object relations a feature of the Generic Object Services could help to provide for the relation of a record, case, or document if written at the time of creation of the object or Folder Management item. Business object relations do relate to pairs of business object type and business object key even across system instances. Members of these pairs should be self-contained, meaning, both instances should carry enough information or attributes to enable their existence independently. With regards to SAP Folder Management, this does require duplication of attributes onto the record/case/document as needed. But at the same time: A record/case/document is a legal snapshot in time! It does require the duplication of information from the business process transaction to reflect what happened at this point in time. In effect, both might be required: Writing a business object relation between transaction and record/case/document Duplicating attributes, that do reflect the state of the transaction or master data at the point in time
Business objects in a record

are not easy to find or query for. The authors of this document strategically did choose for the case to link business objects and a document container for their deliveries to clients. Reasoning was:
10
In case of a one-to-one relation between a business object and a document container, the case attributes could visualize the relation, whilst a business object relation provides for the navigation between case and business object. An example given: The HR employee master and the employee record. In case of a many-to-one relation between multiple business objects and a document container a special case sub-component would visualize the business objects involved and provide for the navigation between the case and the business objects. This sub-component is able to either o o Retrieve business object detail information at run-time the latest information, lets say of a business partner is being displayed, used for authorization checks Store a copy of a point in time of the related business objects involved, in case a snapshot of a current situation is needed. Example given: A contract between parties reflects their current domicilium, corporate IDs, tax numbers, etc. A contract might still be valid after many years but name, domicilium, IDs might have long changed.
In case of a one-to-many relation between one business object and many document containers, again case attributes can visualize the relation between business object and document container, whilst another case sub-component would visualize related cases. Related cases are can be: o o The display of an ad-hoc query on the business object relations table to find other document containers relating to the same business object The display of other document containers intentionally linked by a user. Reasoning: There might be business process going in parallel but not electronically linkable with each other. Example given: One department wants to build new houses on a piece of land, whilst another department is intending to sell this plot. Maybe the link could be the business object parcel of land, but in many situations, strategic planning is way afar from going into the detail. The first department might have chosen to build new houses, but the choice of location had not been made so far.
A 3d view-port
Bridging islands of information (a trademark of then DDSynergy AG and now C1-Solutions GmbH, and fellows along the way of the writers of this document) takes the vision into four words. Eventually it could go along with what is being called mind-mapping, softwares that visualize many inter-related objects, documents, business processes from different view-ports. In 30 or 40 years of ERP software, one paradigm remained unchanged and got never replaced by transactional databases. One finds it when having lunch in an eatery, when doing the groceries, purchasing a house, buying a car, giving birth to a child, or dying because of age: SIGNED PAPER! Records in the sense of signed documents that do express An intention Guide an entity Document a fact or describe a wish of what to be done
11
Are preamble to a (business) relation between parties Describe an ongoing business process Document what had been done
These recordings of facts are still the drivers of businesses, governmental or non-governmental organizations. From a legal view-port, only the paper counts and in many cases it needs to be signed! At the same time, gathering the facts, especially if actions or business processes happened some time ago and/or with resources involved, that are no longer with the entity, information can only be re-gathered if documents, proceedings and processes are well connected eventually openly available. SAPs infrastructure products do provide for these means if well connected and well made use of! This exercise of bridging the gap between requirements and technology should be considered educational. But at the same time softwares do need to evolve in order to meet the legal requirements of todays businesses, organisations and enterprises.
Terminology
PSRM and SAP Folder Management use very different terminology. Thus, conforming on a set of terms is important! This is why this set of definitions is made. Term Record Explanation Folder Mgmt term: The record is an XML based container to represent other objects in an orderly fashion. In PSRM the equivalent is a Part. Folder Mgmt term: A case combines a record and other elements, such as work flow. The idea of a case is, that is being closed. A status network defines the life cycle of a case. A case has a set of well defined Attributes. In PSRM, the case is called a Folder. Folder Mgmt term: A document is a collection of Attributes and Content, to be stored physically in a content repository, while the attributes are kept in the SAP database. Attributes can qualify the type of Standard/Custom Standard
Case
Standard
Document
Standard
12
document, which however is independent of Mime Type. Documents can carry individual access control, can be qualified as living or archived documents and thus might to change its Mime Type from, e.g. MS Word to PDF/A as a long term storage format. A document can be inbound, e.g. scanned or otherwise captured; they also can be outbound, generated through Office Applications or via SAP print programs. A document can exist without a record, case or file plan structure (see MVR). In PSRM, the document is called a Record Folder Mgmt term: Any given business object of the SAP ECC environment. However implemented only rudimentarily and typically stored in the XML record and thus not searchable. A custom extension should combine BO with SAPs Generic Object Services and provide them through tables to enable search. Folder Mgmt term: A means of driving a case or its elements through the organization. However not coupled with the Status Network, that drives the case life cycle Folder Mgmt term: A means of defining the life cycle of a case. Within rates clearance cases connected with an algorithm to precalculate milestones and dates of validity or expiry A trail of changes down to the field level. Folder Mgmt term: Extended to keep track of status changes implying the option of performance measurement PSRM term: A means of organizing a registry of documents PSRM term: A means of structuring a File Plan PSRM term: Based of the Folder Mgmt Case, a substructure to the Class, storing Parts PSRM term: Based on the Folder Mgmt Record, a container to store links to documents A means of searching for individual elements of the above categories. Typically by their attributes. Integration of TREX for a common index provided, can extend to full text indexing, where it makes sense (e.g. MVR
Business Objects
Custom (generic implementation available)
Workflow (Circular and/or Process Route)
Status Network
A prototype built, that determines workflow steps from the change of case status Custom (generic implementation available)
Audit Trail
Standard/Custom
File Plan Class Folder Part
Standard Standard Standard Standard
Search
Standard
13
Navigation
document content is 99% similar across documents, full text does not make sense) A means to bridge from document, record or case to the business objects involved; back and forth. Should be based on the Generic Object Services.
Custom (generic implementation available)

Storyboard Folder MGMT Visions

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Storyboard Folder MGMT Visions

Uploaded by

Copyright:

Available Formats

1

SAP Folder Management A White Paper

SAP Folder Mgmt Visions and Ideas

SAP Folder Management A White Paper

SAP Folder Management A White Paper

SAP Folder Management A White Paper

SAP Folder Management A White Paper

SAP Folder Management A White Paper

SAP Folder Management A White Paper

Poid-Relations versus container linkage

SAP Folder Management A White Paper

PSRM and Parts

Legos put together

SAP Folder Management A White Paper

Poid Relations versus Business Object Relations

Business objects in a record

SAP Folder Management A White Paper

SAP Folder Management A White Paper

SAP Folder Management A White Paper

Custom (generic implementation available)

Workflow (Circular and/or Process Route)

File Plan Class Folder Part

Standard Standard Standard Standard

SAP Folder Management A White Paper

Custom (generic implementation available)

You might also like