 Jack Perry © Copyright Onpoint On Demand 2008-2010 | Jack Perry March 5 2010 08:15:03 AMValue stream mapping is a great way to find the waste in any manufacturing process. It provides an illustration of your current workflow along with important data about customer value-added steps, business value-added steps, and customer non value-added steps. Let's define each of these categories. The best way to categorize the steps in your process is to ask a series of questions for each category. We'll start with customer non value-added steps because that is typically where most of the waste is.
Customer non value-added steps (CNVA):
Does our process include any of the following: wait time, re-keying of job information, temporary storage, unnecessary movement, redundant inspections or rework, counting or inventory analysis, rushes due to poor planning?
By removing some of these steps, how much lead time (total time to deliver finished goods) could we eliminate from our process?
If we reduce our lead times, how much increased capacity do we yield from existing equipment and personnel?
Ask yourself why you take the non value-added steps you currently take in your workflow. Then ask yourself if each step is really required. Does it contribute to reduced risk? Does it make your company more competitive? Or, is it likely that these superfluous steps simply make you feel better? A common theme I see at commercial print facilities is redundant steps in an effort to quality control the process. Rather than add more steps to the QC effort, error-proof it by applying lean manufacturing disciplines.
Business value-added steps (BVA):
Does this process include any of the following: steps required by regulation, certification or program compliance, steps that reduce business risk, steps that include management visibility into the process, steps that keep the process flowing?
Recognize that these steps are really non-value added, but may be necessary. Do your best to reduce the costs associated with these steps.
Customer value-added steps (CVA):
Does this process include any of the following: steps that add features or functions to the product, steps that contribute directly to manufacturing and delivery, steps that reduce price?
Ask yourself if your customer expects to pay for this step. Often in a manufacturing environment we tend to over produce. In other words, we try to deliver more than the customer expects or will pay for in an effort to please the customer. This is nothing more than waste. Ask yourself is your customer willing to pay extra for the steps you take to over deliver. If the answer is no, stop doing it. Good quality is what the customer expects and nothing more. Having a good understanding of what the client expects is an easy way for your company to be more competitive. By asking simple questions up front, you can eliminate over production and unnecessary cost which will make your pricing and margins better than the printer down the street who hasn't asked the questions.
How to build a value stream map:
There are different methods of doing this. I like to start with a simple list of steps in the process. It is also standard practice to start building your map from delivery to customer working backwards through the process. But because our industry is so reactive - we jump into action when an order shows up - I like to start from the beginning of the process. Build a simple list of the foundational steps of the process. Here is an example of a list for workflow associated with a web2print production process:
1. receive order notification via email
2. retrieve job ticket and production file
3. re-key job ticket into MIS system
5. schedule job
6. send job ticket and production file into production
7. impose production file.
8. print job
7. finish job
8. ship job
9. update systems
10. invoice
These are just the high level steps in the process. Each step has a number of customer value-added steps, business value-added steps, and customer non-value added steps that must still be identified and documented.
Convert your list to a basic diagram:
Begin to add workflow details to each step:
Example 1: Receive Order Step
1. view email notification
2. click link to job ticket and asset
How long does each step take? Which category does each step belong in? CNVA, BVA, CVA? Is it task time (time it takes to add value to the job) or is it lead time (time it takes to deliver the job but no add value to it)?
Example 2: Retrieve Job Step
1. log into dashboard
2. open job
3. download job ticket
4. download production file[s]
5. log out of dashboard
6. close browser
How long does each step take? Again, which category does each step belong in? And so on...
Begin to add workflow data to your value stream map:
view email: (task time: 15 seconds) CNVA
click link to job ticket and asset: (task time: 3 seconds) CNVA
log into dashboard: (task time: 8 seconds) CNVA
open job: (task time: 15 seconds) CNVA
download job ticket: (task time: 30 seconds) CNVA
download production file: (task time: 1.25 minutes) CNVA
log out of dashboard: (task time: 3 seconds) CNVA
close browser: (task time: 2 seconds) CNVA
For each step, document the wait time, waste, unnecessary movement and effort, rework, counting of inventory, etc. All these items contribute to the total lead time it takes to get the job from receipt to delivery.
You begin to get a visceral understanding of the waste in your workflow. Just in two steps of a very basic process we have found 2.5 minutes of task time and perhaps hours of lead time depending on when the order came in. And none of the time spent contributes to value-added time the customer expects to pay for. Value stream mapping is a great tool for illustrating waste in the process. It also provides wonderful data that can be used to measure costs. Assume that you process 2,300 web2print orders for 8.5X11 sell sheets each year. In your current process you identify 11 minutes of waste. That's 421 hours. And at $30 per fully-burdened hour it adds up to $12,630 per year. Ouch! Remove the waste and put the money into your pocket.
How to Improve:
Begin to build a new value stream map that reflects your future state goals. Follow the same steps. Begin with a list of the new steps in the process. Map them at a high level. Fill in the details. Now compare the data for the two maps and you have what you need to begin your process improvement initiative.
Great questions to ask yourself while building a future state map:
Does our customer expect to pay for this step?
Are we overproducing?
Do we really need this quality control step or is it redundant?
How can we error-proof this step so we don't have to check it again downstream?
Can we use technology to automate what humans do over and over again?
Use value stream mapping often in your lean initiative. You'll be glad you did. Jack Perry March 4 2010 11:46:00 AMWe always try to listen to our customers and hear what they are saying. The one comment that we keep hearing is the need for integrated shipping solutions in a web2print environment. Apparently shipping a bunch of small orders with short turn times can be a pain. So Onpoint is going to be launching a new product just for small printers. It will launch in April 2010, and should provide a comprehensive set of features at a great value. Here' s the scoop: - Integration with leading web2print systems.
- Scan to ship functionality. Eliminates re-keying scheduled shipment information. Just scan the pick list and print a label.
- Multi-carrier support. UPS, FedEX, USPS, and DHL with domestic and international shipping. Compare prices on the fly.
- Custom pack sheets. Customer A wants their logo on their pack sheet, and customer B wants it blank? No problem.
- Support for numerous label printers. A full list to come.
- Support for leading box scales. Pulls the box weight from the scale directly into the scheduled shipment.
- Order reconciliation and reporting. The shipping product will send all shipping data back to your web2print system and close out the order, trigger notifications, and update tracking numbers.
- Pay as you go.
- No contracts.
- Free support.
- Free setup.
We're pretty excited about it. And hope you will be too. A formal press release to come in April.
Jack Perry February 10 2010 08:43:42 AM Five Reasons Why JDF Will Save You Money JDF is here to stay and with good reason. It can deliver significant financial, operational and competitive advantage to those companies who leverage it the right way. Here are five reasons why JDF will save you money: 1) JDF reduces print production costs by removing manual, repetitive steps from the production process. And lower production costs yield higher gross margins 2) JDF shortens lead time, the downtime that eats into a printer?s value add percentage. Shorter lead times yield higher value add 3) JDF optimizes the equipment on the production floor, generating greater productivity out of existing investments. Greater productivity yields faster return on capital invested 4) JDF also makes it easier to manage order volume variations yielding tighter resource management. When volume is down, fewer people on the production floor reduces overhead cost 5) JDF Reduces mistakes. Less mistakes equals less waste.
Jack Perry December 14 2009 09:16:31 AMThe statement of work (SOW) in a technology project is the document that defines all the details of the deployment. It is the blue print. It's an important document for all parties involved. The SOW defines where a project starts and stops, who is involved, roles and responsibilities, technical deliverables, costs, timelines, etc. And although, no SOW is ever perfect, striving for perfection is not a bad goal. The better an SOW is built; the easier the project will be to manage. For the purposes of this entry, I think it best to simply list the elements that we include in our SOW, along with a brief definition for each. I. Introduction: a summary of what the document is about. It provides a brief overview of the goal of the project, and why it is being undertaken. It should include a brief explanation of the parties involved, who is doing what for whom, and the expected outcome of the project. II. Order of precedent: a brief statement that clarifies the order in which documents should be treated. In most projects there are master agreements, scope documents, a statement of work, etc. It is always helpful to define the order in which the documents govern work to be done. The SOW is usually first in precedent. Eliminate any ambiguity between client documents in this section. III. Scope of work: this section should detail the project objective, i.e. printer A will build a web2print platform for client B to include an online catalog of printable documents, dynamic publishing capabilities, ecommerce, and general reporting. You get the idea. IV. Contract Type: in most cases, an SOW is executed as a "firm, fixed" price or is based on "time and materials". V. Definitions: it is very helpful to build a list of definitions to make sure that all parties are speaking the same language. In past efforts we have been challenged with client understanding of items versus products versus templates. Make sure your definitions are clear and concise and not open to interpretation. VII. Specific Requirements / constraints / special notes: we use this section to document any issues that affect the execution of an SOW. A client may not be able to deliver certain elements of the project until later in the project, and parties must build a strategy for making sure the delay does not impact project deployment. VIII. Roles & Responsibilities: this section should include a summary outlining the roles of each party to the process. Who is the primary contractor? Who is the customer? Identify sub-contractors to the process. IX. Deliverables: Each party will have a list of deliverables. The client may have to deliver lists of administrative and end users, documents for deployment. The primary contractor will have to deliver a host of technical deliverables. Our deliverables section has been organized as follows: a. Client deliverables i. Item list ii. Time line iii. Dependencies iv. Testing and customer acceptance duties b. Contractor deliverables: i. Technical deliverables - the work associated with deploying technology ii. Reference materials - addendums to the SOW (schematics, data, illustrations, etc). iii. Testing scripts for each technical deliverable iv. Timelines v. Dependencies c. Customer Acceptance: the process steps taken by the customer to accept each deliverable of the project. X. Key contacts: this section outlines key contacts for all parties involved including: addresses, phone numbers, email addresses, etc. XI. Meeting & communication intervals: a defined scheduled for how and when the parties to the process communicate progress, issues, questions, etc. XII. Change Control Board: on every project I have worked there have been requests to change elements of the SOW after work has begun. It's bad news, but comes with the territory. The change control board is put in place as part of the SOW to deal with such requests. The change control board is a body comprised of members from all parties who receive, evaluate, and rule on change requests. The board includes the following member positions: a. Executive sponsor: a representative from the client - the person who makes financial decisions resulting from change requests. b. Project manager: a representative from the prime contractor - the only party who can receive a change request. c. Engineering lead: a representative from the party performing the technical work specifically assigned to document how the change request impacts the project d. Production lead: a representative from the party performing the technical work specifically assigned to detail how a request impacts software development and roll-out. e. Customer project lead: a representative from the client - the only party who can submit a change request. The change control board receives, evaluates, and rules on requests to change the SOW. In some cases, the request is deemed to have little impact on the SOW, and can move forward without delay. In some cases, the request can have significant impact on the SOW, and requires additional funds to be approved. The change control board is a tool to manage scope creep; shifting sands that can have dire consequences for all parties involved in a technical SOW. XIII. Knowledge transfer & training process: define how knowledge will pass from those who built the system to those who will use and manage the system. Define specific training to take place. You should include timelines and requirements for training. XIV. Compensation: define how much you will be paid to deliver the project. Define when you will be paid and the increments/milestones associated with payment. XV. Special invoice requirements: include special instructions for invoicing, i.e. client needs the purchase order number to be on all invoices. Conclusion: depending on the size of a project, building an SOW can take several weeks but is worth the effort. Even if a customer simply wants to deploy two templates to a demo web2print system, you should still take the time to document as much of these details as you can. I've worked on several projects that started as simple template deployments and culminated in tens of thousands of dollars and hundreds of hours of time. Better apply best practices to protect your business, and ensure successful outcomes.
Jack Perry November 24 2009 08:25:59 PMAbout 58% of commercial printers have already purchased a web2print system. Over the next two years an additional 18% will make a purchase. As many of you know, the investment goes far beyond the initial software purchase. It's an investment in people, process, and ongoing technology improvement. And here's a tough pill to swallow. You'll need more than one storefront if you're serious about growing your web2print business category.
What drives the need? It's the multitude of ways that corporate clients use print to support company operations. Client 1 may require a catalog of static PDFs supported by a fulfillment program for specialty items. Client 2 may require variable mailers with real-time list optimization services. Client 3 may require online composition of documents shared with a downstream group of users. Client 4 may require serial approval workflows while Client 5 requires parallel approval workflows. You get the point. As you build your web2print business, client demand will necessitate further investment in technology.
But it doesn't have to be the printer making the investment. Smart printers will provide services to help corporate clients to find, evaluate, and purchase their own systems. But then they won't need us you say? They can take their print away you say? Sure they can. However, clients will always need you to provide affordable, reliable, and scalable POD production and fulfillment solutions. That isn't going to change. I'm not suggesting that you don't have to invest in a primary web2print system. You do, and you should. But one size won't fit all. Clients won't buy into a web2print infrastructure that won't meet their needs. If it's your company helping the client to establish their technology platform, and you are providing the necessary core and value added services, they will stick. Smart Printers should make investments in workflow unification; the ability to process POD orders using the same automated processes regardless of the system the order originates from. As more and more corporate clients make investments into their own web2print and brand management platforms, your company will be in a great position to provide the necessary supply chain connectivity to make their program complete.
So how do you help your clients find the right technology? In Part I we talked about team development. In Part II we discussed program requirements gathering. In Part III we discussed building a scope of work; the technical requirements sought in a web2print platform necessary to achieve defined business goals. Part IV deals with technology evaluation and a process for helping your clients to find the right web2print system for their unique needs.
If you have done the requirements gathering correctly, you'll have a strong understanding of client document configuration, and how downstream groups use the documents to meet their needs. And if you've developed an accurate scope of work, you've developed most of the criteria required to evaluate potential technology solutions. The next step is to document the most important criteria. Easy to say. Harder to do. Here is the guideline we have been using for the past two years in our professional service engagements: - the steering committee is best equipped to define the criteria
- some typical criteria include
- measure initial cost of entry
- measure long-term cost of ownership
- score a platform on its ability to meet client business requirements out of the box (meeting 75% of requirements out of the box is a good start)
- score a platform on its ability to scale to meet long-term business requirements
- score the vendors ability to meet all client requirements through professional services - configuration and development support
- score the vendor on financial health
- measure the ease of implementation
- measure speed to market - getting the client up and running
- analyze the vendor for the percentage of revenue reinvested into the product
The process of narrowing down a list of vendors to the best 2 or 3 is fairly easy. But the process of picking the right technology for the long term is much harder. In the past we've used a tool to make the decision process mostly scientific and consensus based. In this case consensus is good. More heads are better than one. More perspectives are better than few.
Onpoint has used a full analytical criteria matrix to accomplish the following: - documentation of decision criteria
- weighted scoring for each criteria
- measurement of technology solutions against established criteria
- final scoring based on the facts.
The first step in developing your matrix is to work with the client to define and document their decision criteria. Then each criteria must be weighed against the other others to establish a scoring system ranging from least important to most important. Now you have a scientific model to work with. As each technology is evaluated by the team, it should be scored in the matrix for each of the criteria. The exercise results in a fully weighted score. The high score is the right solution because it meets the greatest percentage of requirements based on pre-defined criteria.
The matrix we use is attached for your use. I hope you find it useful. Jack Perry November 18 2009 08:50:31 AMIf you own a Web2print system, chances are good you already know that one size doesn't fit all. It doesn't matter what system you're invested in, some customers just need/want something different. We are hearing from printers in increasing numbers that they are supporting more than one storefront, and it represents a serious workflow challenge. On the flip side, more corporate accounts are buying their own Web2print or brand management systems, and simply pointing output files to the printer. So what does a printer do about multiple POD workflows? No worries. Onpoint On Demand can solve the problem. Our Symbio product is a POD production automation system. Symbio takes orders from leading Web2print systems like Pageflex, Saepio and Printable, and manages the production of the job from end-to-end. More importantly, Symbio creates a unified workflow. Regardless of the storefront the order comes from, the production workfow is exactly the same. The results are impressive: - reduced product costs by as much as 80%
- increased speed up to 300%
- increased capacity on existing equipment
- more work out of the same personnel
- greater scalability and fewer process constraints.
We are also hearing from printers that industry consolidation is creating workflow challenges. Printer A owns a Printable storefront and produces work on two Xerox iGens. They merge with Printer B, a company using Pageflex storefront and producing jobs on two HP Indigo 5500 presses. The merged company has disparate ordering systems, varying production workflows, and different equipment. Now what? Onpoint Symbio solves this problem too. Symbio is interoperable with equipment from Xerox, HP, Kodak and Canon. Regardless of where the order originates or the press outputing the job, the Symbio workflow is exactly the same. Jack Perry November 16 2009 09:07:40 PM In order for a web2print steering committee to be able to choose the right technology, a project scope must be developed. A project scope defines business requirements in technical terms. Example: Here is a business requirement converted into a technical requirement as part of a defined project scope. Business Requirement: end users must be able to pay using credit cards. Technical Requirement: the system must support credit card processing for Mastercard, Visa, and American Express. The authorizing gateway must only pre-authorize the card prior to production and delivery of the printed documents. Only after the documents have been shipped should the credit card be charged; controlled by a batching mechanism triggered by the creation of a 'shipped' status in the web2print system. Where business requirements define the features of a system, technical requirements define how the feature must be delivered through specific functionality. Only by defining technical specifics can the steering committee correctly evaluate available technology solutions that can deliver such functionality. I've seen many companies skip the process of scope development; relying on a web2print technology company to convert their business requirements into a viable scope document. There are 50 web2print solutions on the market. Although they all provide similar feature sets, most systems are vastly different under the hood. One system may be architected with very flexible template rules leading to low long-term cost of ownership. Another may have very restricted template rules resulting in the opposite. Both companies can help you to define your project scope, but it's already too late once you've engaged one of them. Take the time to find the right technical resources and add them to your steering team. Evaluating and finding the right technology with an accurate project scope will save your company thousands in the long run.
Jack Perry November 16 2009 08:37:09 AM
Program goals are defined through careful analysis of business requirements. Easier said than done. Like any project, it is easy to lose sight of boundaries; the place your program starts and the place it ends. An easy and effective way to maintain program boundaries is to use a modified Kano chart [kay-no]. Diagram 1.1 below is an example of the modified Kano chart we use in our professional service engagements.
Diagram 1.1 | Requirement: | Must Have | Nice to Have | Don't Need | Don't Know | | | | | | | | Near Term | | | | | | Long Term | | | | | | | | | | |
The Kano chart is an effective way to keep the team focused on business requirements that impact your web-to-print program. It's also an effective tool for helping the team to decide what considerations should be placed in the parking lot and which considerations should be dropped from further analysis.
For each business requirement being considered as part of the program, the facilitator can ask a serious of pointed questions, the results of which determine how the business requirement contributes to the overall program scope.
But first some definitions of the values within the Kano chart:
Requirement: the business need being analyzed by the team.
Near-term: focused on meeting requirements on day one the project goes live.
Long-term: a requirement that may be required at some time in the future in order for the program to be successful and sustainable, but is not required on day one.
Must have: this is a requirement that must be met either near-term or long-term in order to satisfy one or more constituents of the program. Not meeting the requirement will disappoint system users and may affect future program success.
Nice to have: the frosting on the cake. System users will be pleased to have this requirement met, but will not be disappointed if it is not.
Don't need: a requirement that is not needed on day one or anytime in the future based on current data.
Don't know: a program gap. A don't know answer while defining and documenting any business requirement leads to a gap assignment. A don't know must be moved to one of the other values (must have, nice to have, don't need) before the requirement is reconciled.
Practical Application of the Kano Chart Exercise: Example I
Business Requirement: Credit Card Payment Option
Question: Is end-user payment via credit card a near term or long-term requirement for the program?
Answer : Near-term. It's the only feasible way for our independent channel partners to purchase print.
Question: Is end-user payment via credit card a must have, nice-to-have, don't care, or don't know?
Answer: Must have. Our channel will be a primary user of the system on day one.
Result: Payment via credit card is a near-term must have. It should be documented appropriately in your business requirement documentation. Jack Perry November 16 2009 08:33:06 AM
Making changes in your print operation will impact several departments within the company including: sales, marketing, supply chain, finance, channel management, and IT, to name a few. To be successful, you must build a steering committee comprised of stakeholders from each of these departments. The steering committee will have several functions: gathering important business requirements throughout the business, measuring program impact on existing process and systems, and building momentum for user adoption throughout the organization and downstream constituents. Building a good steering committee is very important to the success of your program. Finding the right group of people is both a challenge and a diplomatic two-step. If you follow these basic guidelines, you'll have a much easier time and will build an effective team.
Select personnel who are in the trenches; those who understand business processes but who also report to department heads who can affect change inside their department. In many cases, the person may have a director title: Director of Sales, Director of Marketing Operations, Director of Finance, and so on. The person whom you select should understand workflow and personnel affected by changes in print operations. If the person does not understand how print changes will impact departmental operations, you have gone too high up the food chain. If the person has insight into operational impact but does not report to a department head who can affect change management within the department, you have gone too far down the food chain.
Select an executive sponsor. In most cases, an executive sponsor is self-evident. This person has either been the driving force behind starting a web-to-print program, or they own the responsibility for reducing print cost across the enterprise. The executive sponsor should preside over the steering committee. They will serve as arbitrator should conflict arise among team members. The sponsor will be a liaison to all the department heads. And the executive sponsor can help the team to build and defend financial cost justification for the program.
Select a program champion. The best program champion is the reader of this document. It's you. The program champion is responsible for facilitating team meetings, measuring team progress, holding members accountable for milestones, and maintaining program energy and velocity. The program champion is also the program facilitator.
Establish strict meeting times which have the support of department heads making it possible for team members to participate in steering activities without being overwhelmed by existing workload or pulled into projects that compete for time. The executive sponsor will be instrumental in helping to maintain the availability of team members. Reach out to your sponsor if a team member complains of conflicting obligations or a lack of time to finish assigned tasks. The sponsor can interface with peers in other departments and make sure team members are allowed enough time to participate as an active member of the team.
Establish strict meeting guidelines which are to be followed, honored and respected by all team members. In the team environment all opinions should be heard and considered. Team members bring different perspective to the steering committee. No more or less important than another. Team members should be respectful of each other and acknowledge that each person's job will be affected by the program. Each person has an equal stake in program success. Each person has an equal share of responsibility if the program fails.
Here are some good ideas on guidelines for team management:
1. Use the concept of a parking lot. A parking lot is a place to put good ideas that deserve consideration but may not directly impact your web-to-print program. Ideas placed in the parking lot should be documented and delivered to appropriate department heads for further consideration.
2. Always have the following tools available to support productive meetings: white board, large sticky pads, dry markers and erasers, regular markers, small, multi-colored sticky notes, colored push pins, string and tape. You'll understand why these tools are important as you read on.
3. Always document individual assignments with the following data: assignment name, assignment description, assignee name, assignee email, assignee phone number/extension, due date, deliverable, and impact the answer has on the project. This forces accountability for each team member to come to meetings prepared with answers or they affect team progress and deliverable timeline. The program champion should always maintain the assignment list and enforce accountability by team members.
4. Establish benchmarks; deliverables to be achieved and the timeframe for achieving them. Establish broad benchmarks at the beginning of the project, refining and narrowing the benchmarks as your team passes through different stages of the project. A broad set of benchmarks might include the following criteria: establish the steering committee and conduct and initial meeting within 14 business days ? finish documenting business requirements no later than August 15 ? evaluate the three top technology solutions by September 30. Refined benchmarks might include the following: determine the complete set of document user groups, workflows and payment options for the meeting on June13 - build document standards based on a template-driven workflow by July 9 - have technology solution evaluations scored and circulated by October 15.
Establishing a good team with the right ground rules makes the process of building a web-to-print program much easier and it increases the likelihood of success exponentially. Jack Perry November 16 2009 08:31:18 AM The most important step you can take toward achieving web-to-print program success is making the decision to apply best practices to all aspects of the program. If your company is not committed to applying best practices along with appropriate time, resources, and investment, don't start the program. You'll waste months of effort, hundreds of man hours, and tens of thousands in investment if best practices are not applied. So what are the best practices for web-to-print program development? Here's the list: · Form a team representing all departments affected by changes in your print operation. · Create program alignment across all departments and team members to insure cooperation and participation · Identify an executive sponsor · Identify a program champion · Define operational goals you wish to achieve · Define competitive goals you wish to achieve · Gather business requirements · Convert business requirements into a defined project scope · Evaluate viable technology solutions · Evaluate technology proposals · Evaluate supply chain partners · Evaluate supplier proposals · Develop a statement of work - the program blueprint · Assign program management/project management · Monitor progress through rollout · Establish process for managing your web-to-print program · Market the new operations/capabilities across the company and to outside constituents. · Repeat the process as you improve your program. Over the next few months, I'll define each best practice. I hope you find it helpful. |
|
