| In Chapter 6, we discussed developing code to support your workflow processes. However, how do you know what you need to develop? Workflow must necessarily include all activities from creation through destruction of your content. Since you already have an existing Web site, you already have a workflow process. Is that process documented? Does it include everything from creation through destruction? Does everyone in the organization understand the process? Is it enforceable? With CMS, you can apply a consistent and enforceable workflow process for all content. Depending on your organization, this may or may not be a good thing, but you must understand what your company does and how it operates to effectively implement the right technology with CMS. To make sure you are ready to move to CMS, perform the following exercises to discover if you have enough information about your workflow process. Talk to the business stakeholders. Does everyone who "owns" a portion of the Web site understand how content makes its way to the site? Ask them to describe the process as they understand it. Keep in mind that if you are part of the group that initially created the process, the answer the stakeholder gives you may be what you want to hear, not what actually happens. Review company policies on document/content retention. It is paramount that you understand how your company retains and destroys documents or content. Although most firms have long-standing document retention policies, they do not necessarily have a Web site retention policy. Sometimes Web sites, although they represent a public source of information about your company, are not considered a "document" as defined in document retention policies. It is one thing to keep paper in a box for seven years; it is an entirely different matter to preserve Web content for that long technology changes, products are expired, and computer media radically changes (e.g., do you have a 51/4-inch floppy drive?). You should determine if your legal or compliance department has issued guidelines specifically targeting Web content. If so, these guidelines will be helpful in designing a system that appropriately preserves and/or destroys content, when the time comes (hint: It's not likely to include Content Management Server 2002). In addition to basic guidelines, it is important to understand the parameters of those guidelines. For example, has your company provided standards for Web content preservation format, expectations for recovery, whether it has to be noneditable? Ask questions, get good answers, and your company will thank you. Consider automated and people-based workflow processes. There are typically a number of steps to publishing content on the Web. Some of those steps require human interaction and some do not. When you develop your formalized workflow, make sure to include both. For example, when an author finishes creating content and submits that content for approval, you can automatically send an e-mail to the editor(s) involved in reviewing the page. However, a human must review and potentially edit submitted content. Both processes sending e-mail and reviewing the content must be completed in order for the page to be published, and therefore must be included in any documented workflow. Consider how you implement automated workflow features. A very common workflow process is to send an e-mail after an event (e.g., on submit, on decline, on approve). An e-mail can be a very effective way of notifying that some action has been taken or that someone must take an action (e.g., reviewing content). However, since the e-mail is an automated feature, someone involved in the workflow process may quickly become overwhelmed by the volume. You should consider very carefully how you implement any notification process, or consider alternatives. For example, if you use Outlook as your mail client, consider using the Task List and adding a task to an editor's Task List when they need to review content, instead of sending the editor an e-mail. Although e-mail is the example we used here, there are a number of automated workflow features that will often confound the most well-prepared developer. Thorough testing is the only sure way of catching these oversights before your users do.
In the workflow process diagram shown in Figure 37-3, the subject matter expert (SME) is responsible for beginning the workflow by creating a case study. Once the SME is finished, they submit the posting to the technical director for the practice area. The technical director reviews the case study to ensure that the SME has accurately described the work and that the outcome reflects BOTS Consulting's process for solving this customer's specific problem. If the technical director approves the content, the posting is then reviewed by the practice manager, who also has the ability to make changes to the content; primarily, the practice manager is looking to ensure that the case study fits an "ideal" customer. If either of these individuals declines the case study, it is returned to the original author for corrections. Figure 37-3. Example workflow process for BOTS Consulting 
After the practice area finishes reviewing the content, the posting moves on to the marketing department. Like the practice area, marketing is responsible for reviewing the content. However, in this case, instead of reviewing the content for technical accuracy, marketing wants to ensure that the case study accurately represents the firm. Further, they wish to ensure that the case study is written in the right tone of voice and that any offerings mentioned in the case study are consistently described. Now, without continuing the description of the BOTS workflow, you should be seeing a pattern here. Not only are we providing a visual representation of the workflow, but we're also providing a narrative. In this way, you are providing everyone with a clear understanding of what happens to content as well as who is involved. The workflow diagram and written description will help your business users and the developers create the appropriate workflow actions within CMS. |
