Publishing to the extranet
connectBlue, a Swedish Electronics Manufacturer based in Malmo, deploy two instances of Confluence. They've built a mechanism to drive approved changes out to the customer extranet. I interviewed Mats Andersson, who explained the business problem, articulated the benefits and contrasted their prior approach, which used PDFs and a webmaster, to a new system that uses Comalatech Ad hoc Workflows alongside the Remote Publishing Plugin extension.
|
|
In mid-Sept 2010, I - Martin Cleaver (MC) - spoke with Mats Andersson (MA), Product Manager at connectAB. MC: Mats - can you explain to me the nature of your company, who your customers are and how you use Confluence? MA: Sure - well, our customers are device manufacturers. They embed our components - Modules for Wireless Communication - into their solutions. connectBlue needs to communicate extensive amounts of information with these customers so we set up a on the web a way to share with them. Documented items are reference designs, how-tos, and key interface elements of a PCB. We are always learning, so our recommendations are always evolving; getting information out quickly really matters. |
Before we switched to Confluence we built documentation in Word, and published as PDF. When I say publishing I actually mean "send to our webmaster." He was constantly inundated with changes, and could only do so much in a given day. Backlog and delays were accepted as normal and we curtailed our ambitions for customer communication to match reality.
Once we adopted Confluence our internal production refinement of knowledge only sped up! Whereas we might have published at the end of the week now our Product Team were internally capable of putting content out daily - well - hourly really. Of course, with great power comes responsibility, and we knew we could not share partially finished work with Customers. We still need to publish. Doing so through our webmaster would be completely untenable, so we looked how we could use a customer-facing copy of Confluence.
MC: What thinking-process did you go through to put a Confluence extranet up for Customers?
MA: Well, this is a controlled environment with a select audience. It's not just publish: we use the extranet to gather comments for feedback.
MC: What controls do you need, and how have you evolved putting them in place?
MA: We quickly gravitated to Workflows internally, through defined steps of Engineer, Editor and Product Manager before final approval and Publish. This gives Product Managers the means to see an Engineer's newly submitted documents and to ensure they are not only correct, but complete too, coherent with respect to other documentation.
MC: I can imagine how gratifying an automated solution must be.
MA: Yes, it's so much less frustrating, and many changes are now out within minutes.
MC: Sounds like it has really made a difference.
MA: Yes, and this is beyond Workflows. It's adding Remote Publishing that made it possible. Everyone benefits: customers, internal support and management.
MC: And what's on the horizon. Do you use 3.0? And the Ad hoc features?
MA: We haven't really played with 3.0 but are excited about the possibilities. Allowing Product Managers to make their own workflows means they can fill their own niche process needs. This will be a relief for IT!
MC: And what's in your future for Ad hoc Workflows?
MA: We are now thinking through how to do internal release management for new products and follow the workflow in our development projects. This will add more intricate steps for this more complicated processes.
MC: Excellent, well, we look forward to hearing more about that another day. Thanks for your time!
MA: You are welcome.
