2021

Shadow IT, under control: enforcing data governance through process

Designing a self-contained data-to-print automation flow to produce hundreds of trade documents, forcing teams to own their data through technical constraint.

When I arrived at Bollé Safety as a graphic designer, I inherited a body of technical datasheets in two languages, some of which had not been reissued in five years. They were riddled with discrepancies: wrong EAN codes, obsolete standards, statements that diverged from one document to the next, and visual identities that on their own retraced the company's graphic history. At the same time the American market was growing, which meant adapting documents to local standards and translating them into Spanish, while Europe wanted every one of its languages covered. The arithmetic was simple: without a different method, I was going to spend my days catching up with the past instead of taking part in what was coming.

Director of Operations - Creative Manager

Data architecture & e-commerce, Design System & Guidelines

The pressure always lands on the last link

Underneath the production problem sat a governance problem. Nobody knew precisely who was responsible for what between product data, global marketing content and regional marketing content.

A disorganized process has one constant property: the pressure always ends up landing on the last link in the production chain. In this case the graphic designer, ordered to deliver on time a document whose data, translation and regulatory sign-off are all outside his control.

The cost of that situation shows up on no budget line, which is why it lasts. It gets paid in production time, in internal friction, and in the dissatisfaction of distributors who receive documents with legal weight late, or imperfect.

A tunnel refused, a workaround owned

The obvious solution was to connect InDesign to the PIM through a read-only ODBC link. That connection was refused by the PIM owners, without the reason ever being explained to me, and I never got the green light.

So I built the setup without it. Extraction templates produce structured exports shaped to the needs of each document type, and those files feed the chain. The workaround works, but what it costs has to be named: data freshness is no longer guaranteed by the system, it depends on how regularly I refresh my exports.

I tell it because it is common and rarely said. An automation is also designed against the refusals it meets, and the question is not having the best possible architecture but the best reachable one.

Repairing the data without touching the PIM

The second obstacle was of a different nature. The PIM architecture had not been designed with the product and marketing teams, so its fields did not match actual usage: fields that should have been value pickers typed as free text, single-value fields containing several, fields with no character limit where the layout imposes one.

I handled that gap with computed fields in JavaScript, directly inside EasyCatalog. Where they sit is not incidental: since I had to refresh my exports regularly, a correction applied as a macro on the file would have had to be redone every cycle. Placed in the composition tool, the rewriting rule applies itself to each new set of data.

In parallel I tried to help the PIM owners model their fields more logically. With limited success, for want of a genuine owner of the subject: the data architecture belonged to nobody.

Templates that absorb the language

Automating layout demands a rigor that manual composition forgives. The template has to take content it does not know in advance.

So I built anchored, fluid blocks, approaching print with the logic of the web, and a set of GREP rules so that badly calibrated content never produces an overflow. The most concrete constraint comes from how much length varies between languages: a Dutch text and its English equivalent do not take up the same space, and the grid has to hold in both cases with no human arbitration.

Twelve languages are covered, all Latin script apart from Polish. Japanese and Chinese were outsourced, for two reasons taken together: the PIM at the time did not accept all of them, and the catalog concerned was too small to justify the cost of typographic adaptation.

The last mile

Producing the layout is not enough. Multilingual export and archiving are the least visible and most time-consuming part of the work.

I wrote a JSX script that reads the layer structure, isolates the active languages, and generates the high-resolution PDFs applying the company's naming convention. The operation goes from twenty minutes per multilingual document to three seconds of runtime.

What the automation moved

The most useful effect of this setup is not the time saved, it is the shift in responsibility.

When production depends on data entered upstream, a regional marketing team asking for its datasheet without having edited its content gets sent back to its own contribution. That happens once. On the next request, the content is there and the document ships on time.

It is a way of dealing with the governance problem without having the authority to settle it. Making the deliverable depend on rigorous groundwork produced the engagement that discussions had not obtained, despite initial resistance. And I own having used that leverage in my favor, to move a pressure that gets placed on the designer when it is the brief that is incomplete.

There is also a less spectacular but permanent benefit: no more typos, no more identity mismatch between documents. An automated process has the merit of holding no surprises.

The rebranding test

The method found its definitive justification at the time of the Bollé Safety rebranding: 350 technical datasheets had to be redone in 12 languages.

That volume makes the question rhetorical. Copy-pasting from spreadsheets, the operation is simply impossible inside a launch schedule. It is the kind of deadline that rewards preparation rather than effort.

Why I did not delegate it

I had an alternative, handing these tasks to the graphic designer on the team. I did not, and the reason fits in one sentence I still apply: if I judge a piece of work uninteresting and easy to automate, I see no grounds on which to make someone else carry it.

The economic argument points the same way. EasyCatalog was sold at the time as a one-off license, around a thousand euros. For a company that has to produce 350 technical datasheets, catalogs varied by distributor and by end customer, packaging labels and annual price lists, the return on investment is not up for debate.

This trade side is in fact the one with the most direct return in all of marketing production, and it is also the least valued. Automating what pays without shining frees up time for what shines.

What remains of it

The setup is still in service today, which is the best indicator you can expect from a method. But its recent history deserves telling, because it throws light on its main weakness.

The company has since hired a data architect, and the PIM architecture has changed a great deal. Yet all the rewriting rules I had had to create to fill the modeling gaps rested precisely on those gaps. By correcting the cause, the remedy was made hard to maintain.

That is the intrinsic limit of this kind of workaround: a compensation layer is a debt taken out against the structure it compensates for. It helps immediately, it gets paid for later, and the only real solution remained the one I had been refused at the start.