In most organizations, even those that use catalog software, there is a catalog workflow. At least, there is a workflow that has been accepted for years as being the “official workflow”, but oftentimes it needs improvement. It could be that the way things started out was accurate at one time, and has simply evolved over time (for both good and bad reasons). Or, it could be that the workflow was always in a to-be state but never saw action. Most likely, though, the workflow was accurate up to a certain timeframe—but business requirements change, departments change, responsibilities get passed on like hot potatoes, and before you know it, it’s a tangled web. Making the overall workflow a little smoother reduces frustrations, and further encourages us to look at streamlining other areas.
Why Go Through Catalog Workflow Process?
When trying to improve your workflow (or any process, really), the first thing you need to do is properly diagnose what the problems are based on the symptoms. In the case the symptoms usually revolve around one or more pieces of the workflow routinely getting “stuck” or lagging behind. This causes delays to the others down the chain and has a domino effect.
If you’re not the lagging piece in question, it’s easy to assume that someone else is dropping the ball and point the finger. When you look at the individual situations, however, you’ll often find that there are extenuating circumstances or additional responsibilities that piled up over time which are causing the lags in the first place. Let’s look at 5 typical real-life scenarios to get a feel for how these can play out. Most likely, you’ll recognize at least some of these.
Symptom #1: “The entire catalog creation process seems to take longer than it used to, and we have better catalog software tools and more people involved than we did at the beginning.”
Potential Causes: Do you produce roughly the same amount of pages (same number of products) as you did before? Do you offer any new supplementary material now than you did before, such as spec sheet PDF’s, MSDS sheets, product literature, links to Youtube product videos, or similar?
You want to find out first if this is truly an apples-to-apples comparison. If you’re producing roughly the same catalog you were before, but the overall process has slowed down, then it’s pretty clear there are some inefficiencies to undercover. If you’re now offering a ton of additional value or creating catalogs in multiple languages, for example, then it’s an unfair comparison because you’re producing something quantitatively and qualitatively different than you were before. It’s like trying to compare the production of a 100 page catalog with a 350 page catalog and lamenting that the latter takes longer. Even if you have better tools (such as catalog software) and additional people available for the 350 page version, are you correctly factoring in the additional value and content you’re providing or just clumsily comparing length of production cycles?
Symptom #2: “Updating existing items is a pretty painless process. But, whenever we try to introduce new items, there seems to be a delay before we see them in our system.”
Potential Causes: Is the delay coming from the Merchandising side, the Product Manager, the catalog software, or is it simply related to the data entry process?
If there is no true “staging” process for new items, then this could be a reason why. Ideally, new products are brought in with a special designator like “Draft” to show they are not ready to be displayed on the web or in a print catalog. If this capability doesn’t exist, it may explain why there is a natural delay: the product data would need to be thoroughly vetted and proofed before bringing into that kind of system. Another potential sticking point is that the export / import process may be far from user-friendly. In this day and age, we’re so used to being able to just spit out a CSV or tab-delimited text file of whatever we need. But, if the new product data is kept in some other database or in the form of various Word documents, where an export is not straightforward, this can become more of a laborious task and require manual work.
Symptom #3: “Ever since we added support for (insert foreign language here), our internal Proofing times have significantly increased.”
Potential Causes: This seems like it should be obvious, but it just isn’t.
If your catalog software has multi-language capability (and if it doesn’t, why doesn’t it?), then for most published fields in your database, you also have X other versions of that field data. I say most because for things like “Item Number” and specification values like “Pack Quantity” and “Weight (lbs.)”, the value probably won’t change. Then again, if you’re publishing in Europe it would most likely be a different field called “Weight (kgms.)” because of the metric system. But I digress. Wherever you have your standard published copy fields, you are now managing translated versions for each.
Whether you subscribe to a Translation Service or have in-house translators, this is overhead that is added and must be accounted for. Think about the Proofing process: every time you make a change to a published English field, wouldn’t you need to flag that somehow so your translators know the German, French, Spanish, and Portuguese versions also need an updated translation? It’s easy to see how much overhead this can add just due to the fluid nature of data, particularly marketing copy. If you don’t have a system that can do much of this for you, then it is probably happening manually and you can add even more overhead for that.
Symptom #4: “Photography always complains that they get their shot lists too late, or that they don’t have enough turnaround time when we need new or updated product photos. They are really slowing us down.”
Potential Causes: Just how quickly are they getting their shot lists? How much turnaround time are they getting, and is it reasonable?
This may be a valid complaint once you do some digging. In an ideal situation, Photography is involved from the very start and has an ever-decreasing “shot list” to work from during the catalog building process. If we’re waiting until the Proofing stages to give them this vital feedback, what are they doing in the preceding months? A good catalog software will have this kind of Reporting built-in, so that you can just fire off a quick “Missing Image Report” on a weekly or daily basis. The idea is that it searches out any products in your selected catalog(s) and looks for images that remain unlinked (i.e., “missing”). Once these photos are taken and uploaded, the links resolve and the next time you run the Report, that entry is no longer included (because it’s no longer “missing”).
Keeping the Photography team in the loop much earlier, and having an easy way to give them accurate and to-the-minute feedback, is vital for everyone involved. The Proofing process should be your chance to offer feedback on the images themselves, or suggest alternate shots. It really shouldn’t be the time you “discover” all of these photos are missing.
Symptom #5: “We have source data that comes from a variety of places, and some of them are easier to extract product data from than others. This is increasingly harder for us to manage because we oftentimes are manually bringing in data just because of various technical issues.”
Potential Causes: This is a pretty universal complaint whenever you deal with product data entry that has to go from one system to another.
Ideally, we would all have just one source of data to feed our catalog automation project. Then you are just looking to nail ONE manual process for exporting out data, or ONE automated process which runs on a nightly basis and updates the product information database. The harsh reality is that in most cases, there are multiple sources. Your backend system probably provides the bulk of it, but you may also have Excel files, Access databases, Word documents, InDesign documents, PDF’s, etc.
The more sources you’re pulling from, the more complicated it is to manage and overcome technical snags. We’ve seen cases where exports from an Access database failed, and rather than involve IT to solve the underlying problem, the data was just manually entered into the product database to keep the project moving. Eventually, this becomes the accepted practice because it just works. The burden of the inefficiency is transferred to the person doing data entry.
Spotting Gaps In A Workflow
Once you get the symptoms, you now have a starting point with which you can attack individual problems. A given workflow could have dozens of bottlenecks, and not all of them are easily solvable. But reducing the total number and severity of the bottlenecks is the whole point of this undertaking. You have to adjust your expectations based on the requirements. If the requirements have drastically changed, then it’s not realistic to expect your original workflow timeline to be accurate. Additional requirements almost always result in more work, regardless of where that burden ends up falling in the chain.
It is our belief that any process can stand to be optimized. Reducing or removing even one such bottleneck, like we described in the above scenarios, can have dramatic effects on the overall process. With a clean process, we’re more likely to be true teammates. Of course, the only way any of this can happen is when you get everyone to buy in to the optimization process in the first place.
In Conclusion
Once you have the “true” workflow sorted out, the next step is to get everyone involved validating the individual moving parts. The goal of such a workflow meeting is to identify the inefficiencies and sticking points, and to collectively brainstorm on alternative solutions.
Streamlining all processes which make up the workflow doesn’t just increase overall efficiency and productivity. Ultimately, everyone benefits when bottlenecks are identified and mitigated. A team that better understands the overall workflow (and not just their own “piece”) is a team with less stress and a team that can react more quickly to potential issues.
Book a demo of Catsy PIM Software today.
