Blood Sweat and Tears (Five years of practical experience applying XML/SGML to clinical information)   Table of contents   Indexes   A Travel-Related Case Study Using XML
 

Reuse and Reality: A Journey from Ideal Concept to Real World Implementation
 Mike   Skipper
  Programme Manager
  Motorola PCS-EMEA  Midpoint
Alencon Link
Basingstoke   Hampshire  United Kingdom  RG21 1PL
Phone: +44 1256 790145
Fax: +44 1256 332615
Email: mike_skipper@euro.css.mot.com
 
Biographical notice:
 
Mike Skipper is Programme Manager for user documentation development at Motorola PCS-EMEA where he is responsible for the strategic direction of end user information management and printing. Prior to joining Motorola he held technical, operational, business development and management positions within leading document management consultancies, where he co-ordinated and managed documentation management and consultancy services for companies in many different industries. Mike has 22 years experience in document management, prior to which he worked as a digital design and development engineer for a leading systems manufacturer.
 
ABSTRACT:
 
The journey of a perfect idea into the real world is one often fraught with the perils of 'reality'. Transforming a publication model for mobile phones covering 30 different phone models (and rising) and 32 languages (and rising) into the ideal publication system was no less of a journey.
 
The original system found delays at each stage of the process: authoring, approval and translation of each manual. These problems were delaying the documentation for mobile phones in a marketplace that was demanding new phones models in an ever-increasing rate. The big tasks: study the phone, write the manual, approve the manual, and translate the manual. How could we increase the speed and efficiency of a system where the number of phone models and supported languages were increasing every year? The system was becoming unwieldy and cumbersome.
 
The solution to this problem was born in the revelation of how the software had been implemented for these very phones.
 

Note:


The SGML Buyers Guide, Charles F.Goldfarb, Steve Pepper, Chet Ensign, (c) 1998 by Charles Goldfarb
 

THE BEGINNING
 
In 1994 Motorola were at a crossroads as regards the development, management and production of user documentation. The company's market share of the global cellular market was high, digital cellular was about to take off in a big way with Motorola planning to double its portfolio of products, many more countries were planning to "go live" during 1994. The Internet / World Wide Web was emerging as an alternative media, offering further opportunity.
 
Our current portfolio consisted of 10 basic products most of which were supported in 10 languages, so we already had to manage 100 manuals the average size of each manual was 72 pages.
 
Management had three core objectives for the products which could also be applied to commodities and services which together comprise the product. They were:
 
  •  reduce the cost of manufacture
  •  shorten manufacturing lead times and time to market
  •  improve product quality
 
As far as documentation was concerned, it's development, management and production was considered as a crucial but non-core activity.
 
There was already a small team of people involved in some aspects of user manual development, and an equal number of vendors doing the same thing. So what to do? Grow our in-house team or outsource? We were fast approaching the crossroads; management was demanding our strategy. We had 8 weeks to deliver our recommendations.
 
It was end of June 1994.
 

NURTURING THE SGML CONCEPT
 
Although management were demanding our recommendations as to how we were going comply with the company's core business objectives, I knew deep down that the strategy I wanted to recommend involved the use of SGML, but I needed more time to prepare my case.
 
I had already carried out an initial assessment of our manuals and the suitability of their design for efficient manufacturing and I very quickly concluded that there were opportunities here to save money and slash printing lead-times. If my suspicions were correct these savings would provide me with the ammunition I would need to start the SGML funding process.
 
Our current manual printing and binding specification allowed:
 
  •  2 colours for the body text
  •  up to 6 colours for the covers
  •  wire-o binding
  •  perforating
  •  die cut cards
  •  fold out diagrams
  •  laminating on covers and cards
  •  use of high quality gloss art paper for both covers and text
  •  non standard manual size
 
My proposal for rationalisation was to re-define our manual printing requirements to allow:
 
  •  standard manual size
  •  a single colour for the body text
  •  up to 4 colours on covers for top of the range product manuals, 2 colours for the rest
  •  saddle stitching for all manuals up to 96 pages, perfect binding for manuals in excess of 96 pages
  •  eliminate die cut cards, perforating and fold out diagrams
  •  eliminate laminating
  •  reduce the paper specification
  •  eliminate shrink wrapping
 
We were able to make a saving of £0.50p per manual on average order quantities of 10000. Our forecast for 1995 was to ship around 8million units so the potential for significant savings was there for all to see. I needed to present my thoughts to the commodity managers responsible for print buying for our region, and sell them on the benefits that would be forthcoming. I also needed to work closer with the printers, to better understand their processes so that my ideas for rationalisation could be confirmed.
 
In the meantime day to day manual development had to proceed as normal, and I knew that the internal resources at my disposal were not suitable. It was time to make my first visit to senior management to recommend the first of what was to be several changes in our quest for an SGML solution. I recommended that we outsource our manual development, translation and localisation business. A global supplier had already been identified by the organisation whose core business was printing; I had to work with them to develop their newly acquired information development capability.
 
The question was for how long? It was Christmas 1994.
 

BUILDING AND PRESENTING THE CASE
 
I had already been in the job 9 months and seemed no further forward in my pursuit of an SGML solution. Day to day manual development issues, weekly visits to our outsourcing vendor, to distribution centres in Scotland and Germany and to the head office in Chicago for product planning and technical marketing meetings were keeping me fully occupied.
 
There was some good news though. The rationalisation program had been given the green light and immediately started to pay dividends. I soon had enough statistical information to show consistent savings in our manual printing costs over a period of 6 months, with agreement from our current print vendors to drive the costs down further over the next six months.
 
We had recently announced support for our products in more 10 languages taking the total to 20 with more on the horizon. Our products were becoming more sophisticated and had grown to 20 with the net result being 400 manuals to manage not 100.
 
More importantly though, more re-use was possible as there was a high degree of common functionality across the product portfolio. I was even more convinced that an SGML implementation was the right solution for us.
 
By this time I had spent almost a year being aprophet in my own church and whilst I was quietly confident of what I wanted to do, I really needed a second opinion. Time to call in the real experts, the only issue here was money. So, it was time to reveal all to the management. I was granted a one-hour meeting to convince them to spend some of the money we had saved through rationalisation on a cost benefit and risk analysis, and to further nurture the SGML concept.
 
So it was time to face the music. I could predict and therefore was prepared for questions that were fired at me, like:
 
Why do we need to spend any money on a business case analysis?
 
To have our strategic direction critically reviewed and analysed by experts in the field of information management who will recommend a course of action that will give us longevity of solution and payback against our business objectives.
 
Can't M.I.S. do it for us? After all, they are our computer experts.
 
No. This is a specialised requirement that needs to be addressed by information management experts.
 
What do you expect from the business case analysis?
 
I expect to have my vision for future user documentation fully examined with the result being recommendations regarding the strategy we should adopt.
 
If we do agree to fund this, what do we get for our money?
 
Recommendations regarding the type of system we need for the future to meet the company's core business objectives, along with estimated costs and timescales for the implementation.
 
How long will this analysis take and how much of your time will you need to invest in it?
 
The analysis will take 6 to 8 weeks. I will need to invest as much time as it takes to brief the consultants and provide them with all the information they need to do a good job for us.
 
What is SGML, and why is it so important for us? When all said and done we are only producing manuals that very few people read anyway.
 
We are legally obliged to support our products with instructions on how to use them. If our customers do not read them it is their choice. SGML is an international standard for the format of text and documents. SGML is important for us because it will form the foundation of a solution which will enable us to reduce our user manuals budget, reduce the time to market of our products and to increase the quality of our information.
 
So at the end of an interesting hour, I had convinced our management that the analysis would:
 
  •  Quantify the lead time reduction in the manual development cycle
  •  Quantify and qualify the costs and benefits for the corporation
  •  Examine possible integration with other Motorola corporate IT strategies
  •  Define the requirements for re-use of the data to support internal customer requirements like those of our call centre
  •  Frame our future strategy for manual development (i.e. outsource or in-house)
 
But I also needed to take it a stage further as I wanted to regain some of the time I had lost preaching the SGML gospel. So I also wanted the analysis to identify and quantify those manual development tasks which would best benefit from re-engineering of current processes. For example:
 
  •  Data capture
  •  Data management
  •  Workflow management
  •  Translation
  •  Composition
 
To my relief and after what seemed one of the longest hours I'd ever spent; I came away with permission to spend £15,000-00. We were finally on our way, the journey had begun but I had to make sure that the business case analysis delivered on the commitments I had made, otherwise it would be a very short journey.
 
The presentation of the results of the business case analysis was set for early October; the audience was to be my departmental management.
 
It was end of July 1996.
 
Much of the intervening 8 weeks was spent providing the consultants with the data they need to support my business case. Giving them an understanding of Motorola's cellular business, forecasting growth and the likely impact on manual development, analysing the current situation, examining the effects an SGML solution will have on costs, lead time and information quality and most important, providing real examples that the audience could relate to. I had to trust and have faith in the consultants since they were going to give the presentation. We were ready, in 2 hours I would have a clear indication if our money had been well spent because a decision was promised one way or another.
 
The presentation went well. Unanimous buy-in was secured for an SGML solution and I was given the green light to proceed to the next stage. I now had to scope our requirements in more detail, write a request for quotation and invite three companies to bid for the design, development and deployment of an SGML solution.
 
I was given a further £10,000 to spend on this exercise and retained the same consultant team to assist in this process.
 
The deadline for RFQ's to go out was mid November 1996, responses were due to be returned by mid December 1996, respondents to present their proposals early January 1997.
 
The respondents were asked to define how their solution would address such specific issues as:
 
  •  How it will cope with the effects of increasing product complexity and shorter product life cycles
  •  How it will react to language version re-scheduling due to changes in demand from the market
  •  How it can share data with internal customers that need to re-use the data but publish it in different ways on different media
 
They also had to describe how their solution would meet the key business objectives of:
 
  •  Improving time to market by shortening manual process development lead times
  •  Streamlining the processes for manual development, production and management
  •  Improving user manual information quality
  •  Reducing user manual development costs
  •  Providing visibility of project status through effective management reports generated by the system
 
It was now early October 1996.
 
The presentations were made as planned in January 1997 but to a much wider management audience, including representatives from M.I.S., finance as well as my own departmental management. Benchmarking of the responses was done and a decision was taken to proceed with one of the bidders and discuss commercial and contractual arrangements with a view to placing an order pending funding. However, storm clouds were beginning to gather on the horizon.
 
It was now March 1997.
 
Up until this point, matters had proceeded fairly smoothly if not a little slowly. I now had to go through a similar exercise as before, but this time I had to justify spending £650k and demonstrate a return on the investment within a very aggressive time period.
 
Was my journey coming to a premature end? Or would I along with a growing band of SGML converts be able to continue our journey?
 
Like all big corporations, Motorola has a set process to obtain funding of this magnitude, and I was about to find out just how difficult and time consuming it was to convince senior managers and executives how important this investment was and why they should make it.
 
My justification had to be summarised under the following headings:
 
  •  Executive summary
  •  Financial summary
  •  Present situation
  •  Proposed situation
  •  Decision impact/alternatives
  •  Implementation plan
  •  Funding
  •  Resources
  •  Conclusion
 
Many meetings and several presentations later I had a 24 page document that was fully supported by my management, M.I.S., operations and finance the only signature left was our Vice President's, without it no funding would be forthcoming and all our efforts would be to no avail.
 
It was now August 1997!
 
Imagine, the content of just 24 pages plus one signature would define whether or not our journey would continue. I was left to trust my senior colleagues and new SGML converts to secure the all-important signature.
 
I received the signature I wanted in October 1997. The initial purchase order was raised in the first week of November 1997.
 
By this time we were supporting 30 core products plus their variants in 30 languages. We had also received our long-range forecast of having to support 50 products by the year 2000. That's 900 manuals to manage now, with close to 1900 in just over two years!
 
I need this solution yesterday. Thereal journey had just begun.
 

THE REQUIREMENTS AND ANALYSIS PHASE
 
Work on the project proper began in January 1998. To help with the overall direction and control of the project two groups were formed.
 
Aproject board comprising a total of 6 people, 3 from Motorola and 3 from the prime contractor, whose role was;
 
  •  To monitor, guide and direct the overall project
  •  To review and approve significant changes to the project
  •  Resolve any conflicting issues.
 
Asteering group comprising representatives and project champions from those areas that interfaced with the system, whose role was to advise on:
 
  •  Business requirements
  •  Technology options
  •  Business process issues
  •  Operational requirements
  •  Future plans and enhancements.
 
We also instigated formal project, quality, change and risk management processes, as you would expect with any project of this magnitude and complexity. In addition, a series of project charters were mandated. These documents were our roadmap, and helped frame the activities agreed upon for each phase of the project.
 
We decided to split the project into 3 main phases:
 
  •  Requirements and analysis
  •  Design and prototype
  •  Development and deployment.
 
To gain a detailed understanding of our requirements it was necessary to compare the core functional requirements against the key objectives of the system defined in the cost benefit analysis. The core functional requirements were obtained:
 
  •  By interviewing the main users of the system
  •  At steering group meetings through breakout groups brainstorming how key objectives were to be met by the system.
 
Here are some examples of the requirements defined by users.
 
Program Manager requirements
 
1. The system must generate a variety of reports on-demand
 
2. The system must provide the ability to add, update and delete DTD's, SGML entity definitions, style sheets etc.
 
3. The system must allow me to add new users or user groups and authorise their level of usage
 
4. The system must provide full back-up and restore capability in a pre-defined sequence
 
Department Manager's reporting requirements
 
5. I must be allowed to submit, update and cancel English and foreign language manual requests
 
6. I must be allowed to submit, update and cancel English and foreign language fragment requests
 
7. I need the system to assess the impact of any changes to priorities
 
8. I need to be able to define those feature write ups that should appear in any given manual, in conjunction with the features that are enabled in the software
 
9. I need to support products for up to 3 years after product introduction, so I would like control of archival and retrieval at both the manual and at the feature write up level
 
10. I will need the system to track authoring and translation assignments, I will need training in the proposed workflow software
 
Author's and Translator's requirements
 
11. I don't want to have to worry about keying tags, I have enough trouble getting the content correct
 
12. I need to be able to see in-line images
 
13. I would like to have the authoring tool automatically check for compliance with the Motorola style guide
 
14. I would like to be able to see the reviewer's comments on screen
 
15. I must have an easy way of keeping track of the work assigned to me.
 
16. I need to have contextual references to aid the translation process
 
17. As freelance translators, are we required to use the tools mandated by you?
 
Reviewer and Approver requirements
 
18. I must have the ability to mark up a document electronically
 
19. I need to keep track of the review work assigned to me
 
20. I am a poor time manager. I need the system to prompt me if a deadline is approaching
 
Call Centre requirements
 
21. Right now all we have are PDF files. We'd like the ability to search the information you supply us in a context specific fashion rather than a free text search
 
22. The deliverable to us must be usable on our intranet
 
23. We must be able to access your deliverables using both Internet Explorer and Netscape browser technology
 
Printer's requirements
 
24. We want to pull files when needed rather than have files pushed to us
 
25. Just make sure that the system delivers Postscript and PDF with all fonts embedded
 
Security requirements
 
26. Your system must be fully compliant with both BS7799 and the guidelines issued by Motorola regarding levels of security as applied to information for both internal and external dissemination
 
M.I.S. requirements
 
27. You must comply with Motorola policy regarding hardware and software
 
28. The main server for your system must be placed in a secure location
 
29. Comms and ISDN must be in a secure location
 
Training and support requirements
 
30. Authors will need training on authoring tools and an appreciation of the data repository functionality
 
31. Authors will also need some SGML training
 
32. System documentation and user documentation must be provided during deployment
 
33. Maintenance of the system must be split between Motorola M.I.S. for hardware, operating system a network services and an outsource partner for the SGML environment.
 
As you can see from the above, this is quite an extensive "wish list" which I had to be balanced with time, available technology and of course the budget.
 
Whilst all this was going on, I turned my attention to the software components that we would need to deliver the functionality. The only software component that had been agreed upon was for the data repository.
 
In conjunction with a consultant from the prime contractor, visits were made to conferences such as SGML/XML '97 and to demonstrations of real live applications in different industry sectors. We also met with industry experts and software application specialists to exchange views on applications, their capabilities, and how they mapped into our user requirements and our it strategy. We also made frequent reference toThe SGML Buyers Guide essential reading for anyone who is going through or about to go through the software selection process.
 
Selecting the most appropriate set of software components can be quite difficult and one has to consider many criteria on a component by component basis before making a final selection. For example:
 
  •  Functionality required by the system versus what is offered by the component
  •  Has the component been integrated before and how well
  •  What degree of customisation will be required and how easily can it be achieved
  •  What are the planned enhancements to the component, when are they due and what will they cost
  •  Will they occur during the development phase of the project and should we plan for them
  •  What is the after sales support and training like for each component
  •  How willing are the component suppliers to participate in the design development and deployment phases
 
After giving due consideration to all of the above, our system was beginning to take shape. Our hardware environment was already defined by our corporate it strategy which was PC hardware running Windows NT as the operating system. We had also defined our major system components and had identified and chosen our tools. Refer toFigureSKI-006 - System Component Overview .

System Component Overview
  
 

Data Repository
 
A key element in the architecture of our system is how we manage our content. We did not intend to manage our content at the document level or indeed the file level, our intention was to manage and control our SGML data at thefragment level. This defined our choice of repository component.
 
Astoria fromChrystal Software was selected.
 

Workflow Management
 
This component helps to address two of the key objectives of the system
 
  •  To reduce the manual development cycle by controlling fragment authoring, fragment translation and manual production
  •  To provide an audit trail for management reporting.
 
The product chosen for this component wasStaffware fromStaffware PLC .
 

Authoring
 
Authoring here includes the creation and editing of text, prompt messages and graphics. Our objective was to provide as much of the functionality as possible using the features of commercially available tools and to keep customisation to a minimum. The main authoring tool is theAdept SGML editor fromArbortext . However, Adept does not handle all of our foreign language requirements, in fact, we did not identify a single SGML editor that could. Since we were defining a format with which our localisation vendors had to comply, full linguistic support was not a real issue as far as the selection process was concerned. For graphicsIllustrator fromAdobe was the chosen application.
 

Composition
 
Our selection of composition component was probably the most difficult and was driven by our need to support a wide range of languages. Composition is one of the key components of the whole system and is responsible for producing the final print ready output from the overall system ready for use by our global printing partners. We finally chose a product called3B2 fromAdvent Publishing , an extremely powerful composition system in its own right.
 

Management reporting
 
The system would provide an environment for management reports generation. The component selected for report generation was mandated by our M.I.S. department and is part of our normal desktop tool set and isAccess 97 fromMicrosoft .
 

External interface
 
The requirement for this component was to package up and distribute fragments and complete manuals for review and approval using the PDF file format and transmit them using e-mail. The design and integration of this component had to comply with BS7799, the British standard adopted by Motorola UK for information security.
 
The requirement analysis phase was coming to an end, and I was happy to report to the management that the deliverables for this phase were on time and within budget.
 
It was March 1998 and to date I had a System Requirements document and a Project Charter to show for our efforts. Across the Atlantic, questions were already being asked.
 
We approved the funding for this system 3 months ago, where is it?
 

THE DESIGN AND PROTOTYPE BUILD PHASE
 
We were now entering a most crucial stage of the journey. It had already taken 4 years to get to this point. I was already aware of changes in technology that I knew would influence the way in which software would be implemented in the phones. Very simply, its feature set determines the functionality of a particular phone. The most economical way to create and maintain software for an ever-growing product portfolio is to create a master feature set containing all possible features currently available.
 
When a new phone model or a variant of an existing model is requested, only those features that are required for that particular phone model are enabled. What a great idea!
 
But how could I make sure that the documentation is synchronised to this rapid build process? Why not treat the documentation in the same way.
 
If each available feature was treated as a separate re-usable fragment, then I could mix and match fragments dependent on the model of the phone. SeeFigureSKI-014 - Use of publication fragments in the EDMS system .

Use of publication fragments in the EDMS system
  
 
The key to all of this was to agree on the content of a document that would serve two purposes.
 
  •  As input from product marketing to software defining exactly what features are to be enabled in the software
  •  As input from product marketing to the EDMS system defining which features need to be documented
 
But wait a minute, this is just one issue that has to be resolved, what about all of the others? Many questions were already being asked from within the project team, like:
 
How many fragments are there likely to be? Our low level document analysis already shows that there will be approximately 600 fragments for each of the 30 languages, that's a total of 18000 data fragments!
 
How are we going to keep track of the status of all of these fragments, who is working on them and where they are in the workflow?
 
Will the system cope with all of the current 30 languages plus those that are predicted for the near future like Thai, Bahasa Malay and Korean? Don't forget we have to manage a mixture of language families, Latin, Cyrillic, Greek, Arabic, Simplified and Traditional Chinese.
 
Will the composition engine be fully Unicode compliant in the timeframe we anticipate for the system development? What about font support, particularly for Chinese?
 
How do we handle the display prompts that are contained within the phone that also appear in the fragments that comprise the manual? They will have to automatically change without re-writing the fragment. Changes made to prompts within an English fragment will not require direct modification in any of the languages due to the use of entity references.
 
What about the menu trees that show the order and structure of features that are enabled in the phone? They are different for each core phone type and are currently created as graphics.
 
On the subject of graphics, we need to review the current tool and process particularly regarding the menu trees.
 
Oh, and one more thing, what are we going to do about legacy data?
 
Conversion of legacy data is the ultimate nightmare but I can offer some words of advice and caution.
 
  •  Don't freeze and do nothing and pretend it will go away if you ignore it
  •  Don't dive in head first and create a disaster
 
  •  Do evaluate your approach by:
     
    •  Quantifying how much data needs to be converted
    •  Defining how many source formats there are, what they are and how much data resides in each
    •  Defining the target formats, i.e. SGML only
    •  Accurately defining the elements, i.e. text as well as tables, images, cross-references etc.
    •  Quantify the text elements by page analysis
  •  Do ensure that you have a suitable DTD. You can:
     
    •  Adopt an industry standard DTD
    •  Use an "off-the-shelf" DTD
    •  Design a custom DTD
  •  Do give serious consideration to your conversion methodology. You can:
     
    •  Opt for manual conversion
    •  Choose to convert via custom software
    •  Engineer a conversion process that combines manual and software processes.
  •  Do develop a conversion schedule in conjunction with conversion experts
  •  Do write a conversion specification
  •  Consider developing a tracking database and documenting the conversion process
  •  Do weigh up the advantages and disadvantages of "in-house" versus "outsourcing" your conversion
  •  Do decide how you are going to check the quality of your newly converted data. Remember,VALID SGMLIS NOT necessarilyCORRECT SGML.
 
With so many unanswered questions, it was imperative that we continued as planned and published the Functional Requirements Specification so that our developers, maintainers and recipients could comment on the intended functionality of each component part of the system. But this wasn't going to be enough to prove that our ideas and designs worked in practice. Nor was it going to reassure our sponsors that we were actually making some significant process towards meeting the stated objectives of the system. So in addition, we decided to build a system prototype
 

The System Prototype
 
The purpose of the prototype was to demonstrate the following features:
 
  •  storage of feature write-ups in English and Polish enabling the generation of user manuals from shared feature descriptions
  •  use of the Staffware workflow tracking system to assign tasks to designated users and to track their completion of the tasks
  •  the integration of Staffware and Astoria such that Staffware events can trigger Astoria functions such as check-in, edit and check out
  •  the ability to compose fragments and complete manuals into PDF format for review
  •  the ability to distribute the PDF to designated reviewers
  •  the ability to read the annotated PDF back into the central repository
  •  the ability to produce management reports
  •  reduction in manual development cycle time seeFigureSKI-016 - Process Improvement via EDMS

Process Improvement via EDMS
  
 
For the prototype build, we needed some test data. We outsourced the conversion of sample data to SGML to a consultancy that also provided us with an opportunity to test our DTD's in anger for the first time.
 

What did we gain from the Prototype?
 
The experience gained from the prototype enabled us to:
 
  •  finalise our workflow
  •  finalise our functional specification
  •  test the DTD's
  •  examine some of the composition issues by testing a second language
  •  develop a detailed Design Specification
  •  develop a Test Plan
  •  further develop a Legacy Data Conversion specification
  •  secure buy in from our project sponsors that our efforts and their objectives were going to be met
 
By now Christmas was fast approaching and many issues had been resolved. I had more documents to add to my growing collection. A Functional Requirements Specification, a Design Specification, a Project Charter, a Test Plan, a Document Layout specification and two DTD specifications to name but a few.
 
There were however some unresolved issues pertaining to Unicode compliance, fonts support for Chinese languages and fragmentation granularity. We were showing a slight slippage against the original plan but we were still just about within budget.
 

THE DEVELOPMENT AND DEPLOYMENT PHASE
 
Just when you thought the finishing post was in sight the company decides on a worldwide re-organisation and a review of all projects requiring significant capital expenditure. What a way to start the New Year!
 
I had to provide a further justification to spend the balance of the money I had fought so hard to get which meant an update of the costs to date, the outstanding expenditure and a re-iteration of the benefits the company will enjoy after full deployment. This would be a good test of our project administration, fortunately it did not let me down and the green light was given to continue.
 
My thoughts were now turning to the "roll-out" process and the priorities that I would need to define to make sure that the EMEA region was properly supported. We planned to ship 30 million cellular phones in 1999 and I have to understand and plan how our system will satisfy each individual country's demand. The inputs to consider are:
 
  •  Product Type
  •  Volume
  •  Margin
 
These have to be balanced with the technology we have engineered in our solution and the growth pattern of emerging countries.
 
The affect our new system will have on people and processes, training and support once the deployment is complete will be significant I know. So how do I ensure that the system uptime is maximised so that it accomplishes the goals and objectives we have promised and how do I ensure that the users of the system are happy and productive.
 

Users
 
The success of any implementation rests with the users. Fortunately our users have not been kept in the dark regarding the SGML implementation so they are reasonably well prepared for the transition. However, for those of you that are contemplating an SGML implementation or are in the midst of one right now, these are the key issues as I see them:
 
  •  Fear of the unknown, resistance to change
  •  Loss of control
  •  Loss of ownership
  •  Prefer old tools to new tools
  •  Is the SGML environment an improvement? Structured environment versus desktop environment
  •  New environment a threat to job security.
 

Processes
 
Our environment requires a new set of working processes that mirror the tasks defined for authoring, translation and production. These are controlled by the workflow component and automated in the system. However one area which will change radically is the role of the validator/reviewer of the English source.
 
Thecurrent process suffers from the subjectivity and duplication that de-centralised validation brings, and is carried out at the manual level only. That is to say, validation takes place on a product by product basis by individual product managers on a complete manual.
 
Thenew process consists of two phases:
 
  •  Centralised validation of the content by the technical marketing authority at thefragment level . This means that the responsibility for content is centralised which removes subjectivity and permits more efficient re-use.
  •  Approval of the completed composed manual by product managers focuses their attention towards manual completeness and away from fragment content.
 
I needed to define a maintenance and support strategy that takes into account and balances the practicalities of maintaining an SGML implementation with the cultural. The same old question arises; what do we do in-house and what do we outsource?
 
Our own M.I.S department will look after the "Motorola environment" specifically:
 
  •  the hardware, client and server
  •  the operating system
  •  the networking software
 
Our SGML environment utilises many tools; some customised more than others to meet the functionality we require from the system. It is not planned to have internal resources to maintain and support our new "SGML environment" in its entirety, so outsourcing of the maintenance and support of the following components will take place:
 
  •  the repository
  •  the workflow tool
  •  the authoring environment, including DTD, FOSI's, style sheets, etc.
  •  the composition engine
 
The deployment of our system is too recent for me to comment on "What we did right" versus "What we would do differently" however there are a number of issues which we are continuing to focus on to further improve the deployment and ensure the universal acceptance of this solution.
 
  •  Openly communicate the move to SGML
  •  Establish an on-line help system at the development partner responsible for the SGML environment support
  •  Establish a process to record system enhancement requests from the users
  •  Closely monitor country/language specific localisation requirements
 

Parallel Running
 
One additional very important point to remember is that migration from one environment to another is not like turning off and on a switch. It requires careful planning particularly as you are still expected to maintain a level of service during the transition. Parallel running is inevitable, sodon't ignore it but above alldo budget for it both in terms of time and money.
 

JOURNEY'S END
 
Our journey is finally coming to an end. It has been almost 5 years since we originally set out. Our system is fully deployed but is it living up to expectations? Let me repeat what the objectives of the system were:
 
  •  Improve time to market by shortening manual process development lead times
     
    •  reduced user manual development cycle time by 40%
    •  reduced the time to market for printed material from 3 to 7 days to within 24 hours
  •  Reduce user manual development and printing costs
     
    •  reduced user manual MBR costs
    •  reduced user manual printing costs
    •  remove the need to hold inventory
    •  reduce the risk of obsolescence to almost zero over time
  •  Improve user manual information quality
 
We are gathering statistics to measure the actual savings against those that we originally forecasted, and every indication is that we will achieve our goals. The objectives shown in italics are already being achieved. The improvements in information quality however are not directly measurable, however information consistency is through our workflow management reporting and through re-use.
 
The following are additional benefits that the system is already delivering:
 
  •  improve reporting and control
  •  increase our flexibility of choice for printing
  •  better support internal customers e.g. the Pan European Call Centre
 
So what lessons have I learnt during the course of this journey?
 
DO
 
  •  Focus on the business objectives
  •  Form project team(s)
  •  Communicate. Keep sponsors, future users and potential future users informed
  •  Adopt a formal project management methodology and establish formal plans
  •  Build a system prototype
  •  Be prepared for change and keep an open mind
  •  Monitor technical developments
  •  Involve experts wherever appropriate
  •  Analyse all available tools for each component part of the system prior to selection
  •  Plan for the future
 
Above all else,be realistic , and remember, past presentation traditions and methods should not be sacrosanct;information quality should not be compromised.
 
DO NOT
 
  •  Underestimate the time an implementation will take
  •  Assume. Use the project management tools available to document everything
  •  Underestimate the legacy data conversion exercise
  •  Forget to budget for parallel running
  •  Forget the process re-engineering required
  •  Forget maintenance, training documentation and support
 

THE FUTURE
 
What does the future hold? Well, we have already started to examine where our next journey will take us. Ultimately our goal is to secure approval for a company-wide SGML deployment to mirror our global strategy for printing and therefore drive the rapid development of files for just-in-time print.
 
Clearly this mandate will require executive level buy-in and support from other business unit sponsors. It will also require further communication and education between my area and the various business units to sell the benefits of SGML. Our "global vision" is summarised inFigureSKI-024 - Global EDMS Infrastructure .

Global EDMS Infrastructure
  
 
This shows the convergence between manual development and digital print to deliver to facilitate "just -in-time" deliveries of printed manuals into our worldwide distribution centres.
 
EDMS will form part of a global strategy for information delivery where the underlying architecture and tools would be replicated and customised to suit each region. With fast, secure communications linking the EDMS hubs with digital print centres located close to or within our own distribution centres, true JIT print can be achieved.
 
Within this "bigger picture", we will start to extend the current authoring capability which is primarily focused on paper delivery to authoring for Web delivery. This will mean that we will have to examine the current authoring tools, styles and templates and where necessary re-design them.
 
We are also interested in exploring the integration of "translation memory" and "terminology memory" with our current environment. We are already using SGML as the enabling technology for automatic re-use in both source and translated documents, and to assist in the identification and translation of changes. This is really what drives real cost and time savings. We also need to keep an eye on the development of internet-based translation resources.
 
These are just some of the enhancements we are looking into, I am sure more will be added. One thing is certain, our focus will continue to be on time to market and information quality with cost reduction for development being important but not the primary objective.
 
For some of you this XML 99 conference may be the start ofyour journey. Take full advantage of this opportunity. The experts are here, the tools are here and more importantly YOU are here. You may not have realised but you have already started your journey.
Blood Sweat and Tears (Five years of practical experience applying XML/SGML to clinical information)   Table of contents   Indexes   A Travel-Related Case Study Using XML