Ziegler: Requirements of CMS in TC

Requirements of
Content Management Systems (CMS)
in Technical Communication

Prof. Dr. W. Ziegler

Karlsruhe University of Applied Sciences
Management & Engineering
Dep. Tech. Comm.

Overview

Introduction

1. Reuse (Content, Structure)
2. Change Management (Versions)
3. Variant Management (Product, Media, Target Group, …)
4. Translation (Language Variants)
5. Automization (Publication, Aggregation)
6. Integration (Data, Processes, Systems)

Summary

© Prof. Dr. Wolfgang Ziegler

Organization and information
Sales/
Marketing Manufact.

Develop.

… the black box
Tech Com.
Department

Product
Pre-Sales After-Sales
Information


Information and the product lifecycle

Sales- Require Developer Service-
Doc. ments Service Reports
ERP Hazard Supplier
info
Data analysis Doc.
Configu- Speci- Cust.
rator fication Tech. Desc. Feedback
Standards
CAD-Drawings Certificates
Patents
Models Tests
Regul. Doc.
Partslists

Sales R&D Manufact. Training Service

Product Machine
Catalog User Service- Info
(Web)- System
Marketing
Manual info &
Data- Spare
sheets Plann. Manual
e- Part
Install. Catalog
Business Help
Mount.
Desk
Doc. Training Info
Doc.
CBT/WBT
PIM (PDM) CM SPIM
Product Information Management Content Management

CMS drivers

 Complexity of products
 Dynamics of product development
 Globalization
 Output requirements: quality and cross media


Demanded CMS functionalities (by cust.)

 Object Management (Archiving, Versioning of Content) 44% (80%)
 Retrieval Mechanisms (Search and View) 44% (80%)
 Management of Media/Graphic formats 67 % (85%)
 Reuse 67% (91%) and Version/Variant Control 44 % (79 %)
 Translation Process Management 56 % (76 %)
 Terminology Management 56 % (76 %)
 Cross Media Publishing 44 % (79 %)

tekom CMS-Study 2005/2008: Main CMS requirements


(Component) Content Management

Optimization of internal processes Users
• Technical Writers
• Content Provider
• Information Architects
• Administrators
Authoring Managing Delivering
Requirements for users
• Qualification

Content Management System tekom modules
• “Authoring systems“
• “XML”
• Software supporting optimized processes
• Requirements are defined by processes

10-step introduction procedure (tekom)

1. Analysis of actual state
Process
2. Estimating optimizing potential (Re-)Engineering
3. Definition of future system/state (Requir.)
4. Evaluation and selection of system
5. Specification of implementation
6. Internal preparation Content & Media
Engineering
7. Customizing
8. Installation
9. Training and migration
10. Using and optimizing


Content Engineering (Phase 6)

 Structuring information and use of information models
 Modularization and variant handling
 Metadata and search/retrieval concepts
 Terminology and authoring guidelines
 Styling and publishing of media
 Legacy data und migration scenario

 CMS requirements = support of reengineered content creation


Information Process
Maturity Model (IPMM, JoAnn T. Hackos)

Maturity levels Key Practices
(for analysis & improvement)

Optimizing  Quality assurance activity
 Information Planning

Managed and sustainable  Estimating scheduling and
tracking projects
 Hiring and training
 Innovative information
CMS Organized and repeatable designs to support
customer needs
 Cost and budgetary control
Rudimentary  Quality management
Ad-hoc  Collaboration


CMS Introduction Phases

60
50,4% tekom 2005
tekom 2008
50
40 35,7%

30
20
6,7% 7,2%
10
0


CMS requirements and functionalities

1. Modular authoring and reuse


Modular authoring

Goal
 Decrease document creation time by re-use of information
(„modules“, „topics“, „chunks“, „objects“)

Methods
 Standardized authoring using (XML-) structures, writing guidelines
and language control
 Modular writing and metadata enrichment of modules
 Decentralized modular authoring (in globalized environments)
 Aggregation of documents by (large number of) modules

Balance of granularity

flexibility
simplicity
higher reusability

complexity
lower reusability
redundancy

Modul size

Bottom-up analysis: module matrix

document
Class Doc 1 Doc 2 Doc 3
structure
Chap task Mod 1 Mod 1 Mod 1
1.1 (S) (S) (S)

Chap descr. Mod 2a Mod 2b Mod 2c
1.2.1 (V) (V) (V)

Chap diag- Mod 3
1.2.2 nosys
(O)

doc./prod. variants, media, target group Rockley 2003 („Content Audit“)
Drewer /Ziegler 2010


Spectra of module sizes

% Variant Process Standardized
Management integration Info.models
(Parts Lists)
60 DOG 2000
tekom 2005
40 tekom 2008

20

0


Modules and Metadata?


Metadata examples


Metadata systematics
author („John May“)

status („released“) translation status („in work“
version („4.0“) language („de“)

„life cycle“

component („seat“) mod.type („task“)
„intrinsic
info.type („operation“)
properties“
functional part („ head restraint“) procedure type („removal“)

„Product classification“ „Information classification“

pub.type („online“) „extrinsic
series („169“, „245“) properties
product („passenger car“) doc.type („owner‘s manual“) (use)“
valid ( “A“, “B“)

Practical classification (module matrix)

3-level intrinsic 3-level intrinsic
Koenig&Bauer, information classes product classes
Printing machines


Classification of modules

 use of intrinsic metadadata for classification and retrieval

 (static) folder structure seat

head restraint

removal

 database attributes seat head restraint adjust
back removal
heating

 combination: „dynamic folder“


Standardization (content + structure)

<?xml version="1.0" encoding="UTF-8"?>

<task>

<heading> Displaying structure nodes </heading>

<step> Open file by using code editor. </step>

<step> Activate menue entry <menue> „evaluate“. </menue></step>

<step> Fill-in XPATH-expression. </step>
<result> The selected nodes are displayed in a separate window.</result>

</task>

Rule-based authoring; enforced by editing tools and terminology/language control

Language control

 Writing guidelines &
terminology enforced
 Combination with XML
structure of information
model (context)


Information Models & Editors


Information Models / Standard structures

standardized
structure

Docbook
DITA
S1000D PI-Mod

1 1 project/
3 customer
specific
CMS 2 structure
specific
structure


Standards in use (structure and layout)
50%
47% Content Engineering
42%
40%

30%
Process-Engineering
20%

10%
05% 05%
03% 03% 02% 02% 01%
00%


Building documents (single sourcing)

Metadata
reuse / referencing • Validity
• Version
• Variant

module repository
(Database)


Modular Authoring

Document Aggregation

© 28
Prof. Dr. Wolfgang Ziegler
Prof. Dr. W. Ziegler - Studiengang Technische Redaktion HSKA


2. Change Management (version control)


Change management (version control)

Versions (revision, release)

7. Change in Product
6. (Development and product lifecycle)
5.
4. Change in Content
3. (modules, media, documents)
2.
1. „Change Management“
reflected by versions


Empirical data:
product changements relevant for tech. doc.

Internal (product-based) conditions for tech. doc.

none low medium high very high

Product complexity

Amount of variants
Amount of Changes
in product development
processes
Amount of changes
after product development


Version control

Driver‘s seat in progress

Towing the excavator released


Aggregated documents:
modules and revisions

Version 6.

Revision (version) control
through
content lifecycle meta-data
Version 3. Change management

Version 4.


Cascading reuse and update scenario

document structure
(aggregated modules)

Show new versions
Auto update
module version

Update

push vs. pull
update scenario


Cascading reuse and versioning

5.0 ?.? 3.0 3.1 4.0 2.0 (document)

5.0 3.0

complex versioning, workflow and update scenario


CM After-Sales Document Types

User Manual 92%

Installation Manual 70%

Service Manual 57%

Software Description 53%

Operation Manual 51%

Data sheets 38%

Training Material 36%

Repair Manual 35%

Spare Part Catalogue 34%

Online-Help 33%

Parts lists 19%

Pricing Catalogues 13%


Number of published information products

68 %: 4 - 8 Information Products

16% 15% 15%
14% 13% 13% 13%
12%
12%
10%
8% 7%
6% 5%
4%
4%
2%
2% 1%
0%
1 2 3 4 5 6 7 8 9 10 11
Information product (doc. types)



3. Variants (Product , Document, Media, Target Group, …)


Variant management

Versions (changes)

A B C D

Variants


Empirical data (product variants)

Internal (product based) conditions for TechDoc

none low medium high very high

Product complexity
(Amount of functionalities)

Amount of product variants

Amount of Changes
in product development
processes

Amount of Changes
after product development


Variant management (document level)

 Document (and product) variants C V.2.

= A V.1.
different configurations
of module variants (A, B, …) B V.3.
 Module variants identified
in CMS by metadata

 Module variants show partially identical
metadata (e.g. PI-classification:
„driver‘s seat“ / „adjusting“; A V.3.
Variants:
mechanical or hydraulical suspension)

Variant management (sub-modular)

 „Parameterized“ modules
„Bedingte“ Elemente = Variablen
through variables
and conditional elements

 Automized filtering
through defined metadata

 Requires stable
and enhanced metadata
concept


Variant management (sub-modular)

Module variant A
 Reuse of (small)
fragments
 Management
of reuse pool
(complex metada
or repository
structure) Module variant B

 Requires clear
reuse scenario



4. Translation Management


Language as metadata dimensions

Versions

Languages

Variants

Translation management (CMS – TMS)

Term
DB
CMS
TMS

Interface:
export-import
system coupling

 Translation processes driven by modularization

Use of TMS (within translation process)

No TMS used
Location of TMS

TMS used by translation
service provider

TMS used in house


Localization

 Document structures are often language dependent (due to standards)
 Target languages are created via intermediate languages (relay lang.)
1
2
3
1
4
2
5
3
6
4
7
5
1
6
4
7
3
2
7
6
5 © Prof. Dr. Wolfgang Ziegler


5. Automization


Automized aggregation of documents

 parts list (ERP)
driven
aggregation
or filtering of
modules Generator
CMS:
Modules +
Metadata

BOM
(parts list)


XML-driven publication

 Rules based mapping from structure to layout

Structure elements Rules can be defined for:
automated • target groups
Rules or
manually • media
controlled • Infotype/document type
Layout elements
• localization
• personalization


Cross Media Publishing
XSLT (XML) XML

DTP

XML
HTML
processor
XSL-FO

hh processor
PDF

epub

CHM © Prof. Dr. Wolfgang Ziegler

Rendering of PDF Documents (XSL-FO)

Doc.xsl Doc.pdf

Doc.xml Doc.fo
XSLT XSLFO
Prozessor Prozessor


Rendering of HTML Documents

MOD.xml

Doc.xsl Doc_x.css

MOD.xml Doc.htm
XSLT
Prozessor

Doc_h.css
Doc.js

CM After-Sales Media

Variety of
Audio Manual 0,20%

output media eLearning 4%

Dynamic Websites 7%

Multimedia Docs 8%

Presentation Documents 14%

HTML Documents 21%

Online Help 33%

CD-Application 39%

PDF (Print) 70%

PDF (online) 73%

Print Document 79%


Published media

70 %: more than 2 media

35%
29%
30%
25%
25%
19% 23 %: more than 4 media
20%
15%
11%
10%
6%
5%
4%
5% 2%

0%
1 Medium 2 Medien 3 Medien 4 Medien 5 Medien 6 Medien 7 Medien mehr als 7
Medien

D.S.


6. Integration (information, processes, systems)


CMS integration scenarios

 Data integration
 interfaces: (manual) exchange of data, information
 coupling: (automated) linking between documents, media

 System integration
 Interfaces: automated exchange between systems (ERP, PIM, TMS)

 Process integration
 Workflow coupling (PDM/PLM, TMS)


Coupling of data / information
Sales- Require Developer Service-
Doc. ments Service Reports
ERP Hazard Supplier
info
Data analysis Doc.
Configu- Speci- Cust.
rator fication Tech. Desc. Feedback
Standards
CAD-Drawings Certificates
Patents
Models Tests
Regul. Doc.
Partslists

Sales R&D Manufact. Training Service

Product Machine
Catalog User Service- Info
(Web)- Manual info & System
Data- Marketing
Spare
sheets Plann. Manual
e- Part
Install. Help Catalogue
Business Mount. Training Desk
Doc. Doc. Info
PIM CBT/WBT

Product Information Management CM
Content Management


Coupling of output media / information

Service information, spare part and descriptive information
• Media (PDF/HTML/Mobile) depending on
User Manual use case
SPC/IPC
• Selection and cross referencing
connecting different document types

• Selection of modular information
Service through metadata (product, article,..)
Manual and semantic information structures

• Data and Informationen have to
be product-specific
(depending on product configuration)


PIM and CM (data and system integration)

 A large number of departments responsible for PIM data are also
involved in CMS processes!
• Reuse of
PIM data information
64%
• Coupling of
53%
systems
Data
Graphic
Terminology
Descriptions
W. Ziegler,
PIM-Studi tekom 2006

Service Information Customer documentation


Delivery systems and content integration

 customer and service portales data sheets &shop systems
 helpdesk applications feedback & reports
service info
customer relation
diagnosis & maint. planning
 data and informationen have to
be specific for ETK
product/customer
 various synchronized
PIM
sources of SPC
information (CMS, PIM, SPIM)
 feedback from customer or
field service

Coupling (CMS & PLM/PDM)

 from system to process integration
CMS

Parts lists (BOM)

Change-Management

Qual.
PLM/ERP R&D Marketing Manufact.
management
Service

DMS

Summary


CMS and Content Lifecycle
*** fully automizable

** Versioning, variant control, … Translation
*** TMS ** ***

Modular Modular Building Delivery
Retrieval QM/QA Publishing
Classification Authoring Documents Archiving

** ** * * *** * *** ***

Workflow
Target Cross Document
Group Media Types


Implemented/supported processes

080%
72% tekom 2008

060% 52% 50%
47%

040% 36% 35%

020%

000%


CMS Investment

CMS Invest Number of Employees

50 - 250 250 -500 500- 1000 1000 - 5000 > 5000

16,1 % 6,7 % 4,3 % 2,2 %
Up to 10 000 Euro

10 000 - 50 000 Euro 48,4 % 33,3 % 30,4 % 8,7 % 11,4 %

50 000 - 100 000 Euro 12,9 % 40,0 % 8,7 % 17,4 % 25,7 %

100 000 - 250 000 Euro 16,1 % 20,0 % 30,4 % 34,8 % 14,3 %

250 000 - 500 000 Euro 6,5 % 13,0 % 34,8 % 22,9 %

Up to 1 000 000 Euro 4,3 % 8,6 %

> 1 000 000 Euro 8,7 % 2,2 % 17,1 %


Return on Investment

years
7

6
Estimated Time of ROI

5

4

3

2

1


Use and further development of CMS

59%
60 Process optimized
Integration „internal“
50 CM processes

40
29% 31%
30 21% 2008
tekom
20 2005
10%
10
0


wolfgang.ziegler@hs-karlsruhe.de

http://www.home.hs-karlsruhe.de/~ziwo0001/


Ziegler: Requirements of CMS in TC

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Ziegler: Requirements of CMS in TC

Ähnlich wie Ziegler: Requirements of CMS in TC (20)

Mehr von akashjd

Mehr von akashjd (9)

Ziegler: Requirements of CMS in TC