Free Excerpt: Questions to Answer Before Starting Your SAP DMS Project
Before starting your SAP DMS project, there are a number of questions you need to answer and considerations that you should take into account. At this point in the process, your focus should be more on defining your requirements and goals and less on what SAP DMS can do. After you prepare a solid foundation and plan, the information can be used effectively when you begin configuring and using SAP DMS.
Defining your requirements and goals is critical to project success. It’s much easier to reach a goal efficiently with planning and insight. This chapter discusses the basic considerations you need to address before starting your SAP DMS project.
Defining Which Documents to Manage with SAP DMS
The first step in your SAP DMS project is defining the documents you want to manage. On a daily basis, a business can generate thousands of documents, which make up the intellectual capital and value of that business. Some generated documents are trivial, whereas others are critical to the production and sale of products. Critical documents include CAD drawings, test reports, product specifications, product literature, and financial documents. Without these critical documents, a company can’t create, purchase, or sell goods. These are the types of documents that should be managed within SAP DMS.
If a company is using SAP software, business processes such as manufacturing, sales, purchasing, engineering, and finance are likely being executed and managed within the SAP system. When selecting which documents to manage within SAP DMS, you should select documents that support such business processes. Key documents are then gathered into one location where the business process is being executed. This makes the data more widely available and less difficult to find, and allows updates to be managed in a controlled manner.
You want to manage all documents associated with the engineering change process you execute within the SAP system. Multiple documents are generated and controlled through this process, and these documents should be stored within SAP DMS.
How Documents Fit Into the Overall Business Process
The next important step is defining how the documents you want to manage fit into the overall business process with which they are associated. Are documents created or required at certain steps in the process? With which business objects are documents associated? Map out your business in a process flow. For each step in the flow, you can identify which documents are required. You should look at what is significant about each document and what it feeds downstream or what it triggers.
For example, it’s a best practice that each company has a process for the development and introduction of new products. During this process, certain documents are required to move to the next phase or maturity level of the product design. If you’re in the “prototype” phase of your product design, you’ll need drawings released at a certain status, signifying that they can be used to build prototypes but not production parts. Along with the drawings, you may need documents such as specifications and finite elements analysis reports.
Example
Imagine that you work for a company that produces bicycles. Before a bicycle can be shipped from the factory, a document describing how the bicycle should be assembled by the consumer must be stored in the system, printed, and included as part of the overall package.
The assembly instructions are related to the finished good item material master for the bicycle in the SAP system and may be included as an item in the bill of materials (BOM). You might also have a business process or system check in place to make sure that the assembly instructions are stored in the SAP system before manufacturing and shipping of the bicycle can happen.
How to Search for Stored Documents
With SAP DMS, you aren’t just storing files or attachments. Along with the files, you’re also storing attributes. Examples of standard attributes stored with each file include the following:
- Description
- Owner
- Responsible lab office
Along with standard attributes, you can store additional attributes, which can be used to search for stored documents. For example, if you’re storing CAD drawings you might want to know in which CAD application and release of the application the drawings were created. You might also want to know the size of the drawing and which customers are using it. These are a few examples of additional attributes you might want to maintain.
This is an important topic, and you should make the necessary effort to define and add document attributes that are required to fulfill your search requirements. This will prevent you from creating an unstructured and unsearchable system.
Example
You plan on storing the resumes of all of your employees. When new positions or opportunities become available, you want to be able to search across the resumes to find qualified internal candidates, using the following attributes:
- Employee location
- Salary category (hourly, salaried)
- Willing to relocate
- Skill set
- Languages spoken
- Education level
Searching on these attributes will return a list of resumes that match the selection criteria.
Define the Lifecycle of Documents
Each document can have a lifecycle of its own. Think of a lifecycle as the time from which the document was created to when it becomes obsolete. Steps in between can include times when the document is in one of the following states:
- In work
- Pending approval
- Approved
- Released
At each step of the lifecycle, the SAP system can be configured to act in a certain way or perform certain actions, such as sending notifications when a document reaches the released state.
When a document is in the released state, you can specify that no further updates can be made to the document without creating a new version. The released version remains as history in the system. Imagine that the released version relates to a certain design or release level of a product you are building. Because it remains as history in the system, you can always track back to the documentation that was used to build the product at that specific design or release level.
The Change Control Process
Another item you need to address and plan for before implementing SAP DMS is the change control process. That is, for documents being stored, you need to determine whether updates are controlled through a change control process. A change control process can involve controlling changes to a document through the SAP Engineering Change Management in the SAP system. This is a formal and rigorous process that can include capturing a reason for changes, elements of workflow, and required digital signatures for release. A formal change control process provides you with a complete history of when and why a document was updated, which is important for documents that are critical to business operation.
Let’s take the case of CAD drawings again. Manufacturing depends on these drawings to build the product in a correct manner. If there is no change process in place for these drawings, someone could update them at will and never communicate the changes. As a result, the engineering group might have one idea of how the product looks, and manufacturing might have another, different idea. A business can’t operate in such a manner for any amount of time.
A Formal Approval Process
Before a document can become an official released version, it may have to go through a formal approval process. Typically, documents that are critical to the design and manufacturing of a product, such as CAD drawings, specifications, and design failure mode effects analysis, go through a formal approval process. This process can be facilitated through a workflow process and might require a digital signature. With a digital signature, the user is required to input a user name and password or other type of security information to validate that the user is signing off on or approving the document. The result of the formal approval is a released version of the document with a record of who approved it. Any further changes to the document can be made only by creating a new version.
When a document reaches the Review status, a workflow process is started that sends a workflow notification to a reviewer. The reviewer reviews the document and decides if it should be released or sent back for rework. If the person decides that the document needs rework, he puts the document back into a status of “In Work” and provides the appropriate commentary back to the person who requested the review. If approved, the document is set to a status of “Released” and is locked to prevent further change. For additional changes to the document, a new version must be created. The released version remains in the system as history.
Identify Business Roles and Mapping
You need to make an effort to identify the different business roles that will be interacting with SAP DMS. This role mapping allows connections to process activities and which roles are connected to what people (and jobs) in the “to-be” process. Map the following to each identified role:
- Activities they will carry out
- Number of individuals in each role
- Where the individuals reside (if you have several business locations)
- Training they will require
Identifying the roles allows you to build a complete use case for SAP DMS that goes beyond just looking at a simple set of transaction codes.
Security Requirements
Next, you need to address security requirements for each document. Consider the following questions:
- What roles in the business are allowed to change each document?
- Does the document status need to be taken into consideration?
- When a document is in In Work status, should a select group be able to view it?
- When the document is released, should it be opened for everyone to view?
For example, all CAD drawings are viewable by everyone after they are released for production. A “released for production” design means that the manufacturing group is building a production product and that product is being sold to the consumer. Therefore, the design can be deconstructed and analyzed. Before a design is released for production, while in a “prototype” or “early development” stage, only the project team that is working on the design has access to view or change the drawings. This reduces the possibility of design secrets getting out before the product is released.
The SAP system provides a complex set of conditions you can use to control access to documents. Several conditions can be combined, including document type, status, and authorization group assigned to the document.
You can set up SAP DMS so that, for example, only a person in the role of Document Control under project F1100 can view documents that are in a status of “Pending Review.” After this is done, no other roles will have access.
Defining Which Type of Application Files to Store
Defining the type of application files to be stored within SAP DMS is important. The term application file is defined as the output file of a specific application. Sample applications include Microsoft Word, Excel, and PowerPoint. Each application can be configured in the SAP system to behave in a certain manner when an associated file is launched for display or change.
To define the appropriate application file types, take a look around your business and see what applications are being used. Most likely, it’s a basic set of applications. The SAP system doesn’t restrict the type of application files that can be stored. Therefore, you can store the output of just about any application in SAP DMS.
Document Numbering
Document numbering needs to be covered during every SAP DMS project. Companies have adopted various number schemes for differing reasons. In some cases, companies are using intelligent number schemes, where specific elements of the document number have specific meanings, are human readable, and may have developed out of a lack of having a computer-based system for managing documents. Some companies will have adapted to the idea that numbers have no meaning and are just numbers used to identify the document. In relation to SAP DMS, you need to think about how document numbers will be utilized. Every document stored in SAP DMS will be assigned a number as a system requirement. SAP DMS supports assigning internally generated sequential numbers to documents. SAP DMS also supports assigning an external number, which means that it can support intelligent document numbers if required.
An external number may be alphanumeric, while internal numbers are purely numeric.
When doing implementations, we recommend using an internally generated number for documents as a best practice. Following this practice matches best with how the SAP system functions and limits user input.
Change History Requirements
SAP DMS keeps excellent track of all changes being made to documents stored within the system, including but not limited to, updates to attributes, when object links change, description changes, status changes, and each time a file check-in/check-out occurs. You will want to define your very specific change history requirements to make sure SAP is capturing everything required for your specific use case. As an example, you might consider having a requirement to record each time someone views a document. Some industries have additional audit requirements, in which the SAP change records may need to be extended. The process of extending the change records can be accomplished via enhancements using standard delivered SAP Business Add-Ins (BAdI).
Company A makes military goods. Documents related to its product designs are stored in SAP DMS. Due to legal requirements, any time a user changes a document, who changed the document and when must be recorded. The change record in SAP DMS captures this information as part of the standard change record.
Versions and Revisions
A version in SAP DMS is defined as a separate instance of a document information record that has its own status, such as In Work or Released. It is a snapshot in time. A revision level is assigned to a document version and is associated with a release state. It’s usually used as a representation of a major change. For each document, you can store multiple versions. With each version, you can assign a revision identifier.
It’s important to clarify what these terms mean to your business because they can become confusing. When you start to work with the system and start to speak of versions and revisions, each person may have a different picture in mind because, at times, the terms are interchangeable.
For example, you might create a document and store it in SAP DMS. On storing, an initial version of 00 is assigned to the document. Let’s say you then decide that you want to save your work as a snapshot at version 00. To do so, you can create a new version of the document, to which version 01 is assigned. When your work on version 01 of the document is complete, you want to release this as an official revision of the document. You can release the document through a change control process that associates revision A to version 01. The “revision” indicator identifies to your business users that the document is an officially released document. Further changes will be made to version 02 of the document, and it may take many additional versions until a revision B is created.
Management of Content Versions
Within a specific version of a stored document, SAP DMS has the capability to store content versions of the files stored. A content version for a file is created each time the user checks in a file after a check-out. This allows for a complete history of updates made to the file. The system enables you to activate an earlier version of a file if required. This is a nice function if a later version has become corrupted or you’ve decided to go back to an earlier version. This feature allows you to also meet cases where by law or for liability, you’re required to manage a complete history of file updates.
Searching and Maintenance in Multiple Languages
You should also consider whether you’ll need to maintain certain attributes, such as “description,” in multiple languages. This requirement is not uncommon in large companies that have locations and employees across the globe with business transactions performed in multiple languages. For such situations, the SAP system provides you with the capability to maintain entry, display, and searching of attributes in multiple languages. It is a good idea to plan for this up front because you’ll need to take this into consideration when configuring the SAP system.
Full-Text Search Requirements
Beyond basic searching on attributes (e.g., description, status, owner), SAP DMS offers you the capability to perform full-text searches on stored documents. As part of its overall capabilities, SAP NetWeaver Search and Classification (colloquially known as TREX) allows you to create a full-text searchable index of all documents stored within SAP DMS. Full-text searching capability is popular among users because it allows them to easily search across all stored documents with keywords. An additional advantage with full-text search is that TREX searching is much faster than a database search.
Due to a product change, you need to find all documents that reference part # “P100”. As part of the basic SAP DMS search transaction, you can enter a search term of “P100”, and all indexed documents with “P100” referenced will be returned.
Stored Document Volume and Size
Having an idea of the volume of documents to be stored is helpful because the infrastructure, and specifically the content server, will need to be sized differently to support, for example, 10 thousand versus 10 million documents.
Also, understanding the average size of files being stored will help with network sizing. Document consumers will likely exist in a number of different geographic locations. Depending on where content servers are located, users viewing or changing documents stored in SAP DMS will be accessing files across a wide area network (WAN), which will impact the network’s usage and sizing.
Example
At your company, the creators of CAD data are located in the Detroit office, where the content server is also located. The CAD data can be between 10MB and 35MB per file.
Individuals using the CAD data are located across the globe, in Europe and Asia. Each time an individual from Europe or Asia views the CAD data, it’s accessed across the WAN and downloaded to the local PC. Because the files are very large, this can have a major impact on WAN utilization and on the time the user spends waiting for the document.
To address this, you can install a cache server at the different remote locations. Data is then cached at the remote site the first time it is viewed. Additional requests by individuals at the remote location will first go to the cache server to see if documents can be accessed there; only if this is not possible, will the requests go to the remote content server. If files can be pulled from the cache server, response times for delivering the files to users will be quicker, thereby decreasing the impact on the WAN’s performance.
Locations for Document Creators Versus Consumers
It’s also best to identify the different geographic locations of creators and consumers of documents. A creator is someone who generates and stores documents in the system. A consumer is someone who searches for documents and displays them. If there are a large number of document creators at a specific location, such as at an engineering center, the site may require the installation of a local content server. At locations with a high number of document consumers, such as manufacturing plants, it might be beneficial to install a cache server. Following these two concepts will help decrease the impact on the performance of your WAN.
Document Retention Requirements
Document retention requirements define how long a document should be stored or be available based on business and legal requirements. Therefore, you need to review what your retention requirements are per document.
For example, in the construction industry, it’s considered a best practice to retain all construction drawings and specifications for an indefinite period. Also, studies and reports that relate to a building’s design must be maintained indefinitely.
It’s also best to address how a document should be handled after the retention period has passed. That is, you need to decide whether it should be archived or deleted. Considering document retention requirements is important mainly because the system must support the legal requirements of the business. If a lawsuit is brought forward against your company, you must be able to produce documents that support your case. In the case of product liability lawsuits, not being able to produce proper documentation can lead to catastrophic results.
Your company has decided to keep all CAD data related to a product’s design for a total of 15 years after the start of the product’s production. When this period has been passed, all CAD data will be deleted from the system if the product is no longer being manufactured. To accomplish this, a process runs daily in the SAP system to see if any documents have passed the retention period. If so, they are marked for deletion. Then, using a different process, documents are permanently deleted from the system.
Conversion to Neutral Format for Long-Term Retention
For long-term retention, documents can be converted from their original application file format to a neutral file format such as TIF or PDF. If document retention requirements state that a document should be kept for the next 20 years, it’s almost certain that the application the file was originally created in will no longer function at that point in the future. “Neutral” file formats such as TIF and PDF help solve this problem.
On the release of product and packaging specifications stored in SAP DMS, all associated files are converted from the original Word format to the PDF format. This conversion is carried out automatically by the SAP system when the status of “Released” is reached. The trigger for the conversion is controlled through the SAP Implementation Guide (IMG) configuration and carried out on a conversion server, which is a component of the SAP Knowledge Provider.
Interface with External Systems
If you’ll need to interface to any external systems to pull documents from or push documents to, SAP has a robust interfacing-facing technology, including SAP NetWeaver Process Integration (SAP NetWeaver PI), to support both options. This is an important consideration as you plan the correct infrastructure components to support such an interface.
As part of controlled change process, specific documents are released in System A. These documents also need to be stored in SAP DMS for consumption by users in SAP. During the release process in System A, a message is sent from System A to SAP NetWeaver PI where the message is transformed and forwarded to the related SAP system. When the message is received in SAP, a document record is created in SAP DMS with the original file attached.
Data Migration Requirements
As part of your project, you’ll likely have documents that need to be migrated from an external location into SAP DMS. Consider the following questions when planning your data migration:
- Where is the current location of the documents to be migrated?
- How many documents will be migrated?
- What is the average size of each file to be migrated?
- Which attributes will be migrated with each file?
- Are there relationships between files that need to be built as part of the migration?
- Will only the current version of a document be migrated or will all historical versions be migrated? (Try to spend time determining the value of historical versions before migrating everything.)
- If documents are stored in a legacy system, how will documents and attribute data be extracted?
- What are the validation procedures to confirm that documents are coming into SAP DMS correctly?
Planning your data migration is a crucial step to having a successful SAP DMS project. Answering the preceding questions can help you get a good grasp of the complexity of the migration and plan accordingly.
Training
You must consider how training will be carried out and how you might tailor it to different groups of users. For example, you may have some users who just need to log in to the system and display documents. Their training will be relatively simple in comparison to an administrator type role. The administrator might be responsible for creating, changing, and deleting documents, which requires additional training time.
For training methodology, consider what will be handled in classroom training, online training, or possibly prerecorded training. Classroom training is the most likely delivery method as the complexity of the activities to perform increases.
In an earlier section of this chapter, we asked that you start to think about high-level roles. You can use these roles as a starting point for mapping training requirements.
Organizational Change Impact
Now, take time to look at the organizational change management (OCM) aspects of implementing SAP DMS. When implementing SAP DMS, activities that individuals currently do will surely change, and new responsibilities and tasks will be created. The goal here is to document these activities and how they impact individuals. Some of the benefits of OCM include the following:
- Change is identified early in the process.
- Roles and responsibility changes are communicated earlier in the process.
- The surprise factor is removed because individuals know what to expect.
- Individuals have more time to prepare for change.
- Risks can be identified early, allowing for overall project risk to be reduced.
Company A has a process where an individual receives released documents from the Engineering group via email and then logs into a system to store the released file. In the future, the Engineering group will directly log in to the SAP system and store the released files. In this case, the individual who was receiving the documents via email can now focus on more value-added activities.
Summary
In this chapter, we’ve reviewed important issues you need to address before an SAP DMS implementation. It’s important that you define your goals and prepare for moving into the next steps of your SAP DMS project: using and configuring the system. You should have answers to the following questions:
- What documents do you want to manage with SAP?
- How do documents fit in to the overall business process?
- How do you want to search for documents?
- What is the change control process?
- Is there a formal approval process?
- Which business roles are involved in the process?
- What are the security requirements?
- What type of application files will be stored?
- Do you have any special requirements around document numbering?
- Will you use internal or external numbering?
- Are there any special change history requirements?
- How are versions and revisions used in your business?
- Will you maintain content versions for stored files?
- Do you need to support searching and maintenance in multiple languages?
- Do you need to enable full-text searching capabilities?
- What is the volume and size of documents to be stored?
This was an exclusive chapter from Document Management with SAP DMS, 2nd Edition, by Eric Stajda. For more information about the insiderBOOK and other titles, visit its web site.
Premium
Premium
Premium