aiim case study submission - loqutus study submission.pdf · aiim ecm master case study 3 2....

AIIM ECM Master Case Study 1

AIIM Case Study Submission

Submission number: 257202 Assignment: #3 “Re-aligning the Business” Date: December 5, 2014

Table of Contents AIIM Case Study Submission .......................................................................... 1

1. Executive Summary ................................................................................... 2

2. Problem/Positioning Statement ............................................................... 3 2.1. Assumptions .................................................................................................. 3 2.2. Subtask #1: Describe the future state of working with content, specifically in order to modernize the customer RFP response process ......... 3

2.2.1. As Is RFP Process .......................................................................................... 3 2.2.2. To Be RFP Process ........................................................................................ 4 2.2.3. To Be Knowledge Management Process .................................................... 8 2.2.4. Return on Investment: checking the connected dots ................................ 9

2.3. Subtask #2: Describe the future state of working with content within the GreenPowerOps content delivery process ......................................................... 10

2.3.1. Format: Communities ................................................................................... 10 2.3.2. Security ........................................................................................................... 11 2.3.3. Moderation ..................................................................................................... 11 2.3.4. Community overlap ....................................................................................... 11 2.3.5. Billing model .................................................................................................. 12

2.4. Subtask #3: Explore training and development requirements needed

throughout the rollout ........................................................................................... 12

3. Risks ........................................................................................................... 14

4. Conclusions ............................................................................................... 15


1. Executive Summary

GreenPowerOps is a global leader in alternative energy knowledge. They must address customer RFP’s in time and with high quality. During the past months, many efforts were invested in setting up an ECM program to address several of the pain points of today’s RFP response process. The current RFP response process is slow, uses too much local focus and effort, is mostly paper-based, produces static reports and are not always compliant nor of high quality. To address these issues, 3 topics in the ECM program are outlined and detailed: optimizing the RFP response process, the new content delivery process and the training strategy. The new RFP response process will feature 5 high-level process stages:

- Global base: provides every RFP response with the best global know-how baseline - Local refinements: provides the necessary local accents and compliance - Double-check: allows extra quality checks - Customer review: allows customers to provide feedback on draft documents - Delivery: highly interactive reports are delivered in community sites

The new RFP process is supported by a newly envisioned knowledge management process, featuring a central Knowledge Base (KB). This provides an efficient search experience as well as a great collaboration experience for local and global experts. Thanks to high quality KB content, GreenPowerOps will be able to use a different billing model. The new content delivery process is based on the concept of “customer communities”. These communities are used to delivery RFP response reports. This content is very dynamic and allows easy integration of KB content, fast response and review by customers and higher turnaround for GreenPowerOps. The training strategy for the ECM program focuses mainly on the cultural change needed to support internal and external communities.


2. Problem/Positioning Statement

This document will focus on the following subtasks as highlighted in assignment 3: - Describe the future state of working with content, specifically in order to modernize

the customer RFP response process. - Describe the future state of working with content within the GreenPowerOps

content delivery process. - Explore training and development requirements needed throughout the rollout.

2.1. Assumptions

- There is a substantial volume of knowledge workers, willing to step up and take responsibility in the new way of working presented. Not everyone hangs on to the current state of affairs.

- There will be a dedicated Governance Officer that will detail the governance plans as needed by GreenPowerOps.

- In the subtasks for this assignment, little space is left for integrating Line of Business (LOB) systems and formalize a company- and systems-wide content strategy. Although this approach to content is more than desired, the scope of this assignment seems to be limited, so the answers to the subtasks will not elaborate on master metadata models, integration patterns, xRM/ERP/SCM/HRM/… solutions already present in GreenPowerOps.

- The technical trainings for implementation and architecture are not in scope of this assignment (subtask # 3).

2.2. Subtask #1: Describe the future state of working with content, specifically in order to modernize the customer RFP response process

First, the current As Is RFP process will be used to show the different pains that are tackled with the future state.

2.2.1. As Is RFP Process

The current situation is best characterized as follows: - Slow: the response times for RFP’s are too long. Customers are noticing this. The

time to gather information and deliver it using modern communication methods is taking an abundance of time.

- Local: much of the effort is provided by local offices responding to local RFP’s. Much of the needed information may not be at hands on a local level resulting in slower response times, duplicate work/research and lower quality to the customer.

- Paper-based: much of the speed loss is caused by a paper-based approach. - Information can’t find its way on its own: the number 1 pain today is the lack of an

efficient way of finding content as opposed to searching for content.


- Static: reports are created statically. Experts do not interact with the customer and cannot provide a truly immersive knowledge experience.

- Non-compliant: because of poor RFP process management, delivered content is not handled according to correct compliance procedures.

- No follow-up: the RFP process is not being monitored and is prone to lower quality because of deadlines approaching.

- Quality control: some RFP’s are not always proofread before delivering to the customer, thus delivering lower quality.

Now that we’ve established the main characteristics of the As Is process, let’s focus on how the future content delivery process.

2.2.2. To Be RFP Process

Based on the observations and characteristics, its best to look at a macro-process level of the GreenPowerOps to understand their value-add processes better.

Business Process Map

This BPM exercise is of vital importance to the success of a large organizational change as the one GreenPowerOps is facing today.

Both the RFP response and Knowledge Management processes are key to the GreenPowerOps business. The RFP Response process focuses on gathering knowledge and delivering it to one or more customers. The Knowledge Management process on the other hand is a continuous process that keeps evolving and innovating the company’s KB. As this is one of the key differentiators for GreenPowerOps it is more than a secondary process, it is key to the organization. The RFP Response process will be discussed in high detail for this subtask. The Knowledge Management will then further elaborate on the future state of working with content in a generic delivery process (not the RFP delivery process).

Case Management

The RFP process is a goal-oriented, knowledge-intensive process. This makes it an ideal candidate for approaching it from a case management point of view because:

- It is knowledge/information-centric: the RFP needs to be built using information that is part of the knowledge workers’ and internal or external experts’ experience.

- It requires specialized knowledge workers to decide which steps to take to advance the “case” (i.e. the RFP).

strategy map Strategy Map

Core Processes

Core Processes::

RFP Response

Core Processes::

Knowledge

Management


- It is goal-oriented: there is no standard process to be followed. Knowledge workers will gradually build up the case and decide “ad hoc” what the next step to take is.

- It is unpredictable by nature: although some RFP’s may have commonalities, given the global scope and local accents of the GreenPowerOps RFP’s, straight-through processes cannot provide the way to move forward.

For case management problem domains, one can typically draw a high-level process or state diagram that describes the milestones that are to be reached. The following sketches this high-level milestone map roughly:

High-level states of the RFP process

During the RFP process, content is first gathered on a global scale. This is done using virtual multi-disciplinary teams. These teams are made up ad hoc and can be changed at any time given the requirements of the RFP. For example, if the customer requests a thorough comparison of Wind and Solar energy in areas where Shale Gas could be an alternative, the virtual team would consist of geographical experts, Wind experts and Solar experts. After a while it becomes clear they may need Shale Gas experts and hence broaden their global team of experts. At the end of the first global deepening stage, a rough idea of a response is formed. Next, a more local approach is used for refining the rough ideas formed globally. This ensures a local approach value-add is offered to customers, built on a globally formed base. This local refinement reconstitutes the virtual team to consist of mostly local experts which are highly familiar with local legislation and political situations. They may have been consulted by the global team at first to make sure they weren’t going into a direction that would be locally unviable. After the local refinements, dedicated experts are consulted that have worked on similar RFP’s in similar local conditions. This is an optional phase. Then, after the content itself is created and refined, the authoring and reviewing phase starts which enables GreenPowerOps to effectively monitor the quality delivered by the RFP teams. This phase also includes customer feedback using their RFP external customer community (see subtask # 2). Finally, the RFP “report” is delivered to the customer. In contrary to the As Is situation, this will not be a static report, but rather a piece of work that may be maintained for a certain amount of time by GreenPowerOps – as agreed with the customer. This allows the customer to provide feedback to the RFP teams and ask additional questions. This allows for an immersive knowledge experience to the customer that will not be found at any competing organization. Not only does this direct the goal in-process, but it also adds efficiency to GreenPowerOps, so they don’t focus on RFP areas the customer is less interested in.

Business Process RFP Process

Gre

en

Po

we

rOp

sG

ree

nP

ow

erO

ps

Deepen problem

domain globallyRefine locally

Detail with local/global

experts

Author and review

response

Deliver to client &

receive feedback


ECM Support

Now that the high-level case management phases that will be used to complete an RFP are outlined, it’s time to detail how ECM methods will support the RFP process to deliver more ROI for GreenPowerOps.

Information Governance

Governance is key to success. In the RFP process, a governance plan needs to be established that defines:

- The responsible for each RFP: this could be an account manager, or a hybrid expert/account role.

- The sponsor for the RFP processes: this will typically be the sales director that is responsible for achieving sales excellence in a certain geography or vertical.

- The role of each participant in the process and each phase of that process: what is the role of the local expert in the Authoring & Reviewing phase? Who hands over the document to the customer? Who receives the RFP request? Who decides on the virtual team constitution? Who approves the ad hoc teams? What is the escalation path in the RFP process?

- How RFP contributors will be trained (see subtask # 3). - What policies and standards will be used. - What metadata framework will be required (see next). - Security: who is allowed to see what in the RFP process? - Compliance: what are the retention policies and other local and global compliance

requirements for the RFP process? - Which tools, formats … to use in the RFP process. - Retention policies: when do documents get archived and when do they get

destroyed, together with the responsible to make the decision for destruction. Note: as the scope of this assignment is growing, I will leave the governance plan in this form rather than making choices myself.

Content Types & Classification

When talking about the RFP content to be gathered, processed and delivered, 3 types of documents are typically found:

- The RFP deliverables - Input documents gathered by the virtual teams - Processed findings on the input documents (i.e. “work documents”)

RFP Deliverables

The deliverables need to be classified rigorously to be able to gather them later on in the content delivery communities. It is important to have the following metadata for RFP deliverables:

- RFP Number - RFP Responsible - RFP Sponsor - Customer - Country/Regions: using geolocation and affected radius to be able to find nearby

deliverables easily - Community reusability: indicates to what extent the document can be shared with

other customers, ranging from confidential to public, note that redaction plays a big factor here


- Validity: indicates how long the information remains valid before it is archived and marked obsolete

- Technologies: lists all technologies form a Technology taxonomy (multi-select single hierarchy)

- Applicable legislations: lists all applicable laws and regulations a document adheres to (multi-select single hierarchy)

Input documents

These documents are typically gathered from the Knowledge Base (see 2.2.3 To Be Knowledge Management Process).

Work documents

These documents are drafts in progress and will result in RFP deliverables. They have the same metadata as RFP deliverables but do not require all metadata to be filled in. This ensures that both the document content and the metadata grow throughout the RFP process.

Document format

The documents described here are not necessarily linear documents like Word documents, but are more likely to be more interactive Wiki-like pages that allow interactive charts, drill-down data sets and embedded audio and/or video material. This allows a more modern delivery and fits in the “digital enterprise” paradigm rising these days.

Document collections

Every document for an RFP process shall be contained within an “RFP Document collection”1. This content type aggregates all documents for the RFP. The RFP document collection also contains the following RFP metadata:

- RFP Number - RFP Responsible - RFP Sponsor - Customer - Validity: indicates how long the information remains valid before it is archived and

marked obsolete The “community reusability” and “Country/Region” metadata are not used on the document collections to enable diversity in the individual documents.

Capture and creation

Documents are ideally born digital. There is a possibility to automate scanning of input documents not found in the knowledge base, but the document imaging strategy is to avoid any analogue documents, as they are less searchable, even with good OCR technologies. They also can’t be reused easily in RFP deliverables, in contrary to digital documents, which can be integrated more easily.

Collaboration

The document collections facilitate working together on documents by giving each RFP a collaboration dashboard with social conversations, integrated reporting and easy R&D tools

1 I deliberately chose not to use the term “document set” as used in Microsoft SharePoint to avoid confusion. The ideas presented in this case study are inspired by SharePoint document sets, but go beyond what can be achieved there.


that point back to the knowledge base. The responsible team members (both local and global) are listed. Communication widgets allow ad-hoc meetings and video sessions with all team members available at that time.

Search & Retrieve

Searching RFP’s will typically happen less than in the As Is situation. In the past, employees would look for knowledge used in other RFP’s that would typically be dated. Thanks to the new Knowledge Management process, finding and retrieving information is easier thanks to great taxonomy and refinements, see more in the next paragraphs regarding the new Knowledge Base.

Publish & Deliver

See subtask #2 for the new content delivery process based on communities rather than pure deliverables. It is already worth mentioning that RFP content that is actually delivered to the customer can be reused, based on the community reusability. It is however important to note that extensive redaction will need to be performed to filter out any confidential customer information that other customers are not supposed to see. This process is highly automated, but receives frequent manual checks from the legal department. These are just a few of the supporting ECM methods that can be used. For the sake of simplicity and completeness in other sections of this assignment, further details are omitted.

2.2.3. To Be Knowledge Management Process

The greatest shortcoming for GreenPowerOps is undoubtedly a usable knowledge base (KB). This Knowledge Base would need to support the following characteristics:

- Findability: finding content should be possible using keywords, as well as using media type (document, report, community, social conversation, people), geographical region, applicable legislation, … Every deliverable community that is still active (i.e. contains valid documents and conversations) can be searched and will also be found in the knowledge base, even if the community is discontinued. The content is constantly redacted so no confidential information leaks from customer to customer. The limited document metadata set was chosen deliberately. It is accompanied by full-text search to provide better content scoring. At the same time, the search and index services are knowledgeable about the duplication of content throughout different internal and external communities and will not list duplicate content in the search results.

- Usability: thanks to optimized search algorithms and heuristics, the knowledge base returns personalized and up-to-date content first, which provides higher usability in the RFP process.

ECM Support

Information Governance

Every KB entry must be governed by a virtual moderation/validation team, consisting of rotating teams of global and local experts, guaranteeing information quality and in-time archival of outdated material.


Content Type & Classification

The content types of the KB entries are aligned and synchronized with the RFP content type (except for the RFP specific data and customer). This is achieved by applying a central master metadata model and pushing it to the different processes (RFP and KB). This allows easier reuse of KB content in the RFP process and easier content extraction from the RFP’s back to the KB.

Capture and creation

KB entries are gathered from the RFP processes’ output as well as self-performed studies which are also added to the KB.

Collaboration

The GreenPowerOps’ KB allows extensive collaboration options. Users are able to collaboratively author the KB entries, converse about them and extract content in multiple ways using the same search strategy as in the RFP dashboards. They can even organize “Refresh-KB” events in which they score virtual points by contributing to KB entries in a limited timeframe. This event-driven collaboration is bound to become legendary within the organization and will cross geographical and cultural borders by engaging employees in a way never imaginable before. The virtual points can then be used to buy company-branded merchandising or attend interesting international conferences hosted by GreenPowerOps (e.g.). This type of collaboration will allow “thought leaders” to stand up from the crowd and take over the KB governance.

Search & Retrieve

As mentioned a few times before, finding content is no different than in the RFP process.

Publish & Deliver

Publication is purely internal, but may have crossovers with the RFP documents in terms of content, albeit redacted. Normal redaction is not applied as the KB regards internal documents, but RFP documents that were gathered inside the KB may be visibly redacted, indicating which information should not be freely disclosed, but not hiding the information from the information worker.

2.2.4. Return on Investment: checking the connected dots

The To Be processes presented just now, will increase ROI significantly by alleviating the pains faced today:

- RFP response times: thanks to the extensive and innovative Knowledge Base, information is found easily. The RFP Collaboration dashboard on the other hand allows members in virtual teams to communicate more efficiently, even when geographically disparate. At the same time, the focus on global knowledge with local refinements increases quality.

- Thanks to the global basis and local refinements, the RFP process starts with a broad vision, which GreenPowerOps RFP’s lack these days.

- The future state is completely digital, hence avoiding paper-based slowdowns. - The new Knowledge Base allows faster and intuitive finding of critical content. - The reports are delivered in the form of interactive communities (see subtask # 2),

hence a more immersive experience can be offered.


- The RFP process can be monitored when orchestrated in a BPM or ACM platform (Adaptive Case Management). This allows better control of compliance. This also provides better follow-up of the RFP status, reducing delivery times even more.

- Thanks to the many time reductions, more time is freed to spend on quality control, making sure the customer only gets high quality deliverable content.

Success Metrics

The ROI is a valid metric, but Total Cost of Ownership is more important in the long run. Quantifying the reduction of time-to-market for the RFP’s can surely be done, but will require more input from GreenPowerOps to be quantified numerically. But it should be clear to the reader that the reductions in time are considerable both in quantity as quality. Expected reductions are well above 35% of the RFP response time. Thanks to the reduction of RFP response time, the knowledge workers have more time to invest in the internal KB and supporting the deliverable communities (see subtask # 2).

2.3. Subtask #2: Describe the future state of working with content within the GreenPowerOps content delivery process

This subtask will mainly focus on the aspects of the content delivery process not discussed in the previous subtask. It will focus on the deliverable content of the RFP process. The content of the internal KB will have similar characteristics. For the sake of conciseness, this subtask will be scoped to the RFP process’ content delivery. The innovative character of the future content delivery process lies mainly in the fact that GreenPowerOps will no longer deliver static documents to customers by default. Smaller RFP’s may still have rather static documents, but the gross of content delivery will be in a new format.

2.3.1. Format: Communities

For every customer, a community is created during the RFP process of the first RFP. A community consist of multiple building blocks which allow the customer to be involved more closely and will also make the information more dynamic and tailored to the customer’s needs. First off, a community is created per customer. This means that when a customer orders several RFP’s, they are all contained within the same community. For each RFP, each community entry is tagged with the RFP number, allowing multiple RFP tagging. Communities contain the following artefacts and functionality:

- Draft RFP deliverables: provided by GreenPowerOps, unfinished pieces of work will allow the customer to provide feedback and refocus based on the direction the document is going at that time. This is performed in the 4th step in the High-level states of the RFP process (see before).

- Approved RFP deliverables: also provide comments and Q&A - Comments on entire documents: general feedback provided in conversation-style

used by both GreenPowerOps and the customer - Inline comments on documents: specific conversation-style feedback on any

document element (paragraph, section, tables, figures, words, reports …)


- Community-level Q&A: allows the customer to ask specific questions to GreenPowerOps during and after the RFP response process.

- Community KB: GreenPowerOps can select specific internal KB articles that can be shared with several customer communities. Special care is taken for redaction purposes.

- RFP-level management instruments: allows digital delivery, review, validation and sign-off for the RFP process, without the need for paper-based intervention (using e.g. digital signatures stating the RFP has been received and has been approved by the customer)

- GreenPowerOps “brain picking” search: allows the customer to find an expert they need within GreenPowerOps and direct questions directly to him/her

- Geographical search for community entries - Allow the customer to search the entire internal KB (redacted) and ask access to

documents. The corresponding price is also shown for accessing the given resource. Depending on the billing model, this may or may not be free of charge, but the request always needs approval by GreenPowerOps.

2.3.2. Security

Customer communities are isolated from each other. Information in RFP deliverables is always fully available to the customer, but some side-info or specific document requests may be redacted versions of internal KB content.

2.3.3. Moderation

Communities can only survive by active moderation and genuine interest by the customer. The customer can decide who participates from their end, but GreenPowerOps must make sure that the community stays animated and interested. This is a big culture change for both customers and GreenPowerOps. Active moderation from GreenPowerOps is required to follow-up on customer questions, to post recurring KPI’s of community usage, promote customer champions, provide feedback and animate using input from the customer on their interests and pains. Besides moderation, animation of the community can be achieved using smart incentive planning. By using a system similar to “Refresh-KB” internally, “RFP Slams” can be organized on customers’ communities that give (part of) KB articles for free if they engage enough in their own community (hence the KPI posting). GreenPowerOps’ interest in customer engagement in the communities is that they can find out what lives in current markets and anticipate questions from future customers in time to study the question in high detail and provide high quality material shortly after the first question is raised. There are lots of possible incentive models for keeping a community active, which are left to the reader’s imagination.

2.3.4. Community overlap

From the previous paragraphs, it is obvious that the internal KB and customer communities will have quite some overlap. Redaction is critical as well as good rights management and governance.


Information Rights Management (IRM)

The governance plan should include several fallback mechanisms and checks that allow GreenPowerOps to keep being in control of who sees what. It may even be important that GreenPowerOps employees don’t get access to all documents. And customers should not be able to freely distribute the RFP deliverables. It is critical for the survival of GreenPowerOps that information is only provided to the customer it was intended for that the customer can only access the information using the customer’s community, and cannot print/modify/download/distribute the contents presented to him/her. It should be noted that redaction also needs support for IRM. Every redacted edit should be kept hidden in the final document, and technically impossible to revert for a customer.

2.3.5. Billing model

Notice how the new community content delivery process drastically changes the GreenPowerOps billing model. From a per-report bill directed specifically to customers they are heading towards recurring community support and pay-per-view KB articles. This allows GreenPowerOps to invest more in knowledge development. Deliverables are more easily interchangeable thanks to redaction techniques, which allows GreenPowerOps to share these documents with more customers, where each customer pays as they view the document. GreenPowerOps moves from a product delivery company to a services model.

2.4. Subtask #3: Explore training and development requirements needed throughout the rollout

The main success factor in any ECM program is user adoption. To engage users and train them, a sturdy training program should be developed. This section elaborates on a high level what this means for GreenPowerOps. Training must be performed during several stages of the roll-out. To start, the core ECM team needs to be trained to understand the ECM program scope and possible elements it contains. This includes sponsors and higher management. The information must be presented in a concise yet effective and results-oriented way. Good knowledge transfer will lead to strong sponsorship, which is essential for the success of the ECM program. Next, the analysts that will go through all of the details - not covered in the previous sections - need to be trained. This requires intensive training of business and functional analysis, specifically on how ECM problems need to be analyzed. Throughout the ECM program, several readiness trainings are to be administered to key users and end users. Key users are the users that will be involved closely in the project. They need a good understanding of ECM from a functional point of view. They must be trained accordingly. A single training will not suffice. Knowledge and skills are best retained when repeated at least 3 times. This can be achieved by providing time slots every month in which the key users can provide their own topics they need more information about during ECM analysis. At the


same time, some static content is presented to refresh their skills and knowledge. This occurs as long as the key users are consulted. These are mandatory sessions. The end users (or key users no longer being consulted) are mostly being involved in communication during the pre-production phase. During business and technical assessment they will typically receive one-way communications, communicating program status and challenges, to keep them up to date and keep the ECM program top of mind. There should also be more freeform they can attend to dig deeper into the consequences it may have for them, and focus on “what’s in it for me”. This should use input gathered in analysis from the key users directly. Most users won’t respond to these optional sessions. A good way to motivate them is by creating surprising and rewarding incentives for them to participate. See who cares the most. See who cares the most regardless of the incentive. Promote them, foster them, cherish them and evangelize them. Make sure they spread their enthusiasm. Then, several weeks before the go-live of an iteration, users need to be warmed up. They should attend mandatory training sessions (close to the actual release date), receive targeted communications about the added value being delivered (“what’s in it for me” again), and be involved in social events regarding the release (if applicable, feasible). Note that training should be provided by certified and experienced trainers, rather than key users being pushed into that role without any experience. Differentiating your audience is important as well. Not all users are at the same level of understanding ECM. Do not create a “smart” and a “dumb” group. Make mixed groups and let them teach and motivate each other. This should provide with the necessary support to motivate most employees. Deal with the sceptics. Make them part of the “double check” group. Make them part of the test team and development cycle. They will continue having criticism. Hear them. Respond. They will eventually see they are being heard, take pride in it and push the program further. Not all sceptics will be convincible, e.g. when their job function disappears. Talk to them. Make sure they feel heard. Empathize. Specific training needs to be provided for the communitization of GreenPowerOps employees. Most of them will be responsible for the animation and support of the RFP deliverable communities for customers and the internal KB. This requires different soft skills and a cultural change. This can only be achieved with gentle transition. Make them see what communities are. Let them use Facebook/Twitter/LinkedIn during working hours. Let them be part of other communities and contribute to them during working hours. Make policies for the amount of time they can and should spend in those communities and what they can and cannot contribute. Let them feel the benefit. Then, engage them in the thinking process of customer communities. Give them time to see the benefit for the customer. Make them see the new reality. Then, find out which of the (key) users are up for the challenge of animating a community. Test drive with one or two customers. This alone will be part of the training and change process. This entire training/communication/change process should be governed internally by an ECM program change manager that is in charge of constantly polling users and their perception of the program. To state it bluntly, the most important part of the ECM program is marketing. Selling the new reality to your users. Succeed in convincing the toughest crowd, so GreenPowerOps customers will love the new way of working.


3. Risks

- The cultural change is already beginning to form, but the ECM program governance team needs to be especially careful for resistance to cultural change or even the impossibility to change culture, due to long-formed habits. Working like communities is completely different than static report delivery. The training and change team is mandated to deal with this, but the approach taken requires at least some users open to evangelization and championism. Absence of this type of users may damage the ECM program.

- Customers may need to be educated as well. Even though the new type of content delivery is what consumerization of IT is all about, some customers may not want this kind of deliverable. Pushing forward may risk GreenPowerOps losing customers. Communicating this change and differentiating in the market may attract new customers however.

- The explicit use of redaction in this assignment tries to cope with any legal issues that may arise due to sharing content that was produced for different customers. This may however not be sufficient for the legal policies in place at GreenPowerOps. This is a significant risk in providing a new reality for content delivery.

- Another legal risk is the fact that last-stage draft documents are already shared with the customer, to be able to comment for a last iteration of content authoring. This may not be compliant with current legal policies. They may need to be rethought. If not, the new reality may be a great risk to GreenPowerOps.

- The success of the redaction engine is crucial for the viability of the internal and external communities. Finding or developing such a redaction engine is a tedious task and contains lots of risk. Most of these should be tackled up front to see if the presented way of working is viable using current state of functionality in the market.


4. Conclusions

This report summarized several aspects of the ECM program roll-out. The future RFP response process will converge two core processes of GreenPowerOps: the RFP response process and the knowledge management process. The RFP response process will be modernized using a case management approach. The high-level steps to go through start out with a global phase to gather the rough picture for the RFP. Next, local refinements are applied. Then, an interactive review phase is started with the customer. Finally, the RFP response is delivered to the customer using an interactive community format. Content delivery will be reimagined using customer communities. These communities will provide rich RFP content including images, videos, drill-down reports and social conversations. This will provide the customer with a rich and immersive knowledge experience and open the path to a more services-oriented billing model. Training is performed throughout the ECM program. Extra emphasis is applied to the cultural change of communities. Users need to understand how they can animate and support communities.