Preparing Your Data for ECM


Published on

Presentation from AIIM Greater Los Angeles Chapter Meeting on Feb 24th. Pilar C. McAdam, CRM, ERMm
Director of Business Intake and Records
Sheppard Mullin Richter & Hampton LLP

Jim Higdon
Senior Director of Information and Strategy
Vendor Direct Solutions

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • (Pilar) How we know each other & the inspiration for this talk; we worked on a complex conversion and started documenting what we thought would be interesting for other Content Managers Our perspective working on records & information management started to shape the scope and landscape of the implementation project We come from the Records Management community, but our message is that those who appreciate how information is used – regardless of their title or department – play a critical role in making a conversion project successful.
  • Quick explanation for newbies (Pilar)
  • Not format specific, not industry specific, not application specific (Jim). You may choose to do a conversion or you may be forced to (merger/acquisition).
  • But there are some basic concepts we must understand if we are to be taken seriously by the technical department. They hold the keys to the gate. (Pilar) Pain examples: 1) dataLOK to Iron Mountain: didn’t have room for all the text fields, so had to eliminate a field for tracking contract number (decision made by upper management). This meant that event triggers based on contract could no longer be used or put into practice. 2) Client acquired a new office, mid-project, that had an additional database that wasn’t appreciated or accommodated. In trying to keep to the original schedule, it was decided to ignore this database. However, it turned out this data was very important for that office, and the project ultimately had to be expanded to rework things.
  • Who the common players are, focusing on a project where the applications have been established – not the product selection phase (Jim)
  • (Jim) to define who these people are and that sometimes they wear multiple hats; the current project we worked on had dedicated project managers, for example. NOTE: There may be one or more players who are not strong for their assigned role, so others on the team will need to absorb some of their responsibilities. May even be some reluctant participants. Give me a show of hands: if you’ve been involved in a data conversion project, who did NOT have at least one team member who was a roadblock?
  • Pilar talking about a key concept and a big AH HA; the systems have grown over time organically but the introduction of new systems is forcing changes to the way we operate. Leads her to question how did this information; how valuable; how reliable is it; is it better coming from another source? What are your pain points today, and how can you use that to help guide your conversion?
  • (Jim) 1. Cannot get away from creating a flowchart documenting current processes; not IT’s strong point documenting processes; this is also where you do an analysis of your current application and how it works. It never hurts when analyzing your current system if you have information about your new system.
  • (Jim) Mention depending on the complexity of the project you might have flowcharts that demonstrate the current processes, the interim processes, the ultimate or future processes (THE STAGES).
  • (Pilar) Just because your organization has done something that way forever does not mean that it’s the best way to do it; Redundancy!!!! Talk about data that has been entered into multiple systems so TALK LEAN; who should be the keeper of the information. AGAIN QUESTION EVERYTHING. If your system is connected and maintained by other systems operated by other groups, these are stake holders and these people will be invited to table
  • (Jim) At a very basic level, what does this information represent? What business purpose is it supposed to serve? Where is it coming from? Is it feeding other systems. Mention “dependencies”.
  • (Jim) A LOT OF VARIABLES that will dictate how you convert your data If the source and target formats do NOT match, there are strategies to use logic to accomplish the goal ( transformation ); you need to understand both the source and target formats. (Examples: date/time formats, document numbering/sequence) --- We’ll give you some examples of formats in a couple of slides.
  • (Pilar) to lead off this slide talking about the forms and how to get data into the tables behind the scenes. It all boils down to the information in those tables – business purposes: Display useful information Calculate values Create reports
  • Pilar to lead in
  • (Pilar) You will see these terms on the data mapping document, the document that developer will use to convert the data. Flag will have one or another value
  • (Jim) Audit trails in many systems are relying on system generated values
  • Pilar: There will always be differences between systems. Talk about her dataLOK to IM conversion: employee number field example Talk again about configuration options, come up with some good example: Location code (for office of origin) – will new system accept existing way of designating locations?
  • (Jim) Come up with some examples of logic used to transform data (something using excel spreadsheets; another source) The mapping process is a group effort and arduous.
  • (Pilar) You might decide to drop tables; give examples; don’t assume because it is in your system now it will come over; cannot be on autopilot … need to pay close attention.
  • (Jim) So once you have analyzed your data, mapped your data, the group has reviewed and agreed to the logic used in the mapping, your developer is going to write the necessary scripts to migrate this data; this is the first pass at the conversion. You will make multiple passes depending on the results. Compare the source application to the target application side by side.
  • (Jim) Finding out what worked is typically called data vetting. How do you recognize a successful conversion? Who will need to participate?
  • (Pilar) Check list here as well as a handout (steps from the design, analysis, configuration phase through the mapping, conversion, vetting of multiple passes to final pass phase)
  • Preparing Your Data for ECM

    1. 1. Pilar C. McAdam, CRM, ERMm Director of Business Intake and Records Sheppard Mullin Richter & Hampton LLP Jim Higdon Senior Director of Information and Strategy Vendor Direct Solutions Preparing Your Data for ECM
    2. 2. What is a data conversion? <ul><li>The process used to translate data elements (information) from one location and/or application (the source) to another (the target). </li></ul>
    3. 3. When would you convert/map data? <ul><li>Changing from one system to another </li></ul><ul><li>Combining data from 2 (or more) systems into one (merger/acquisition) </li></ul><ul><li>Connecting 2 or more systems together so that data can flow from one to another </li></ul><ul><li>Automating a process </li></ul>
    4. 4. Why should you care? <ul><li>You want the project to succeed </li></ul><ul><li>You have a stake in the final result; you need to be able to speak to the participants in the project </li></ul><ul><li>If it doesn’t work right, you’ll feel the pain </li></ul><ul><li>Pain is bad </li></ul>
    5. 5. What the presentation is about <ul><li>Introduction to data conversion: </li></ul><ul><ul><li>Concepts </li></ul></ul><ul><ul><li>Terminology </li></ul></ul><ul><ul><li>Typical steps </li></ul></ul><ul><ul><li>Roles </li></ul></ul><ul><li>High-level </li></ul><ul><li>Every project is unique </li></ul>
    6. 6. Who does what? <ul><li>Project Manager (PM) </li></ul><ul><li>Database Administrator (DBA) </li></ul><ul><li>Developer </li></ul><ul><li>Business Analyst/Records Manager </li></ul><ul><li>Consultant(s) </li></ul><ul><li>Data Owners/Stakeholders </li></ul><ul><li>System Users </li></ul>
    7. 7. Data/applications shape processes <ul><li>Your source data is the result of current applications and processes </li></ul><ul><li>Converting the data will change how you operate </li></ul><ul><li>Use this as an opportunity </li></ul>
    8. 8. Where do you start? <ul><li>Flowchart current processes </li></ul><ul><li>Learn and be able to explain: </li></ul><ul><ul><li>What the content is </li></ul></ul><ul><ul><li>How it’s used </li></ul></ul><ul><ul><li>Where it goes </li></ul></ul><ul><ul><li>Screen prints from source </li></ul></ul>
    9. 9. Develop a Roadmap <ul><li>How does the content get captured and used today? </li></ul><ul><li>What’s the optimal way to manage it? </li></ul><ul><li>Will there be multiple stages to get from “ now ” to “ optimum ”? </li></ul>
    10. 10. Analyze Processes/Systems <ul><li>Are there steps that don’t make sense or don’t add value? </li></ul><ul><li>Is data being entered multiple times into the same system and/or other systems? </li></ul><ul><li>Are there integrations with other applications? If not, should there be? </li></ul><ul><li>Is content being captured from the best source? </li></ul>
    11. 11. Data Conversion Basics <ul><li>Understand how the content is used and its business purpose </li></ul><ul><li>Where does the data come from? </li></ul><ul><ul><li>Transferred from other systems </li></ul></ul><ul><ul><li>Entered from forms or other documents </li></ul></ul><ul><ul><li>Who uses it and what for? </li></ul></ul><ul><ul><li>Does it feed other systems? </li></ul></ul><ul><ul><li>Are other processes triggered? </li></ul></ul>
    12. 12. Data Conversion Basics, continued <ul><li>Understand both source and target data formats </li></ul><ul><li>To avoid loss of information: </li></ul><ul><ul><li>Target format should support the same features/data constructs as source file </li></ul></ul><ul><ul><li>If it doesn’t, you must use logic to transform the data </li></ul></ul>
    13. 13. How ECM Applications Work <ul><li>Set up a series of tables </li></ul><ul><li>Multiple interrelated tables will contain pointers to keep things connected </li></ul><ul><li>Provide an interface for: </li></ul><ul><ul><li>Capture of profile information by end users (metadata) </li></ul></ul><ul><ul><li>Data populated directly into a table </li></ul></ul><ul><li>Perform transactions that use those tables to achieve a business purpose </li></ul>
    14. 14. Sample Table Layout Table Name Field Name Required Data Type Description Default Value Doc destroy_status No char (1) Has this item been destroyed? Yes/No (‘N’) Doc entered_by Yes int Link to employee who created this record in the system. Doc event_date Yes datetime Date that an event will happen (or did happen) Doc event_desc No varchar (100) Description of the event that occurred Doc notes No varchar (1023) General notes field for this record
    15. 15. Common Data Types <ul><li>Variable character (varchar): alphanumeric </li></ul><ul><li>Integer (int): numeric </li></ul><ul><li>Date/time (datetime) </li></ul><ul><li>Character (char): flag (e.g. yes/no, on/off) </li></ul>
    16. 16. Typical Field Characteristics <ul><li>Required (nullable/mandatory) </li></ul><ul><li>System-generated (e.g., today’s date) </li></ul><ul><li>Field length </li></ul><ul><li>Normalized (look-up/discrete values) </li></ul><ul><li>Default value </li></ul>
    17. 17. Configuration options in new system <ul><li>How do source and target assign values for: </li></ul><ul><ul><li>System generated </li></ul></ul><ul><ul><li>Sequential </li></ul></ul><ul><ul><li>Numeric versus alphanumeric </li></ul></ul><ul><ul><li>Can a field be blank (is it nullable)? </li></ul></ul><ul><ul><li>Unique identifiers (e.g., document ID) </li></ul></ul>
    18. 18. Converting data <ul><li>May introduce logic to perform conversion </li></ul><ul><li>Validate mapping and logic with team </li></ul><ul><li>Explain the logic to developers: </li></ul><ul><ul><li>They will write the program (script) to move the data per the rules </li></ul></ul>
    19. 19. Should you convert all content? <ul><li>Can some content be excluded? </li></ul><ul><li>Too old </li></ul><ul><li>Target doesn’t have a place for it </li></ul><ul><li>Easily available elsewhere </li></ul><ul><li>Not relevant to the business purpose of the application </li></ul>
    20. 20. First pass <ul><li>Set up a test environment </li></ul><ul><li>Run conversion routine </li></ul><ul><li>Find out what worked, what didn’t work ( data vetting ) </li></ul>
    21. 21. Data vetting/testing routines <ul><li>Never, ever, ever, ever assume that “it will all come out just fine” </li></ul><ul><li>Test, retest, and test again </li></ul><ul><li>Use a variety of scenarios </li></ul><ul><li>Plan for multiple passes </li></ul><ul><li>Expect more passes than you plan for </li></ul>
    22. 22. High-level checklist <ul><li>Create process flowchart for existing system </li></ul><ul><li>Analyze source content </li></ul><ul><li>Understand target configuration </li></ul><ul><li>Map </li></ul><ul><li>Convert </li></ul>
    23. 23. High-level checklist, continued <ul><li>Find out what didn’t work and why </li></ul><ul><li>Remap </li></ul><ul><li>Reconvert </li></ul><ul><li>Use, rinse, repeat </li></ul><ul><li>Document final configuration </li></ul><ul><li>Train users and deploy </li></ul>
    24. 24. <ul><li>Questions? </li></ul>
    25. 25. Questions? Pilar C. McAdam, CRM, ERMm [email_address] Jim Higdon [email_address]