Unless something happens that requires a pretty quick response, this will be my last post of 2011. And since it’s the end of the year I thought I’d do like so many others and take a look back. However, I’m not looking back at stuff that happened during the year; I’m going back to 1991, to a project and period in my career that I really, really enjoyed. I consider it the first ECM project that I worked on, though I’d never heard of ECM at the time. It’s also the first independent consulting gig that I took on.
In September of 1991 my wife was asked to move from the Montreal area to the Toronto area for what was supposed to be a maternity leave replacement as one of her colleagues had just had a baby. Since the alternative was unemployment for her, and since I wasn’t working anyways (I was back in school) we decided to make the move. The company she worked for was a small distributor of electronic components (switches, plugs, receptacles, etc.). Their clients were mostly in Canada, with a few in the U.S. Their suppliers were predominantly in Europe and Asia, with a few in the U.S. They also had to deal with transport companies and customs brokers/agents in order to carry on their core business.
My wife’s job was to handle sales orders, purchase orders, customer service, transportation, and customs (I did say it was a small company). Other roles in the organization included one accountant/bookkeeper, some sales guys, a general manager, a warehouse dude, and the owner (one of the nicest guys I have ever worked for or with). I was engaged to implement some accounting / order processing software for them (ended up selecting ACCPAC vWhateverWasCurrentIn1991). I eventually ended up doing double-duty as the IT / Warehouse dude (regular whse dude ended up in jail, I ended up reporting to my wife – oh the fringe benefits).
This company was really excited to be getting their first computerized system of anything. Included in the bundle of stuff that they were getting was a rockin’ 24-pin, tractor fed, colour, dot matrix printer to handle their multi-part forms. They could only afford one colour monitor so there was a discussion about who’d get it and who’d get stuck with the grey-scale monitor. The fax machine used rolls of thermal paper (I’m sure at least one of you reading this has no idea what I am referring to). Printing to the correct printer was controlled by turning the switch on the printer switch box (I still have one in my basement somewhere). Everything, even the stuff that was born digital, was stored in filing cabinets, and everyone had their own copy (we hoped), whether or not they needed it.
Every customer, supplier, and vendor had a file. These files were kept in the GM’s locked office, which wasn’t generally a problem until his love life fell apart and he started taking “mental health days” several times a week. Orders from the customers came in by phone or fax. Faxes were great, especially when several orders came in overnight and needed to be separated from each other using scissors. Confirmations from suppliers were received by phone, fax (see point about customer orders), and mail (sometimes after the order itself). Customs paperwork came in by courier (time was of the essence) or fax. Outbound paperwork was couriered, faxed, or mailed. Sometimes the same document was delivered by all three methods, just to be sure. Internal – internal paperwork was walked to the recipient, except for the out-of-town sales guys who got their stuff via fax (including a nude picture from a calendar we got from a Taiwanese supplier – very tasteful, too bad I sent it to a customer by mistake, oops).
But, they had ACCPAC now. I don’t remember exactly which modules I implemented for them, but G/L, A/R, A/P were part of the mix. Not only did they have automated accounting software, we even went so far as to try to eliminate some paper duplication and streamline some processes. There was certainly some resistance (mostly from the accountant/bookkeeper but she went batty, got fired, and hid a CDN$36k tax bill in the customer invoice files). The point is that there were improvements made, even if we couldn’t apply automation to everything. And I made really good money (by the standards of the day), wasn’t on the clock 24/7 (no cell phones or internet), had plenty of time for me (and my wife/boss), and delivered a project I felt really good about. As things turned out, the company offered my wife and me permanent positions, but we missed Montreal so declined and headed home.
If I had to do that project over again today I would, assuming that the client could afford my rates. I’ve learned a lot (and made mistakes from which I’ve learned) over the last twenty years, so I certainly wouldn’t do things the same way, process or approach wise. The biggest difference, however, would be in the technology. Not only are the tools we have available today much better than what they were back then, they’re enormously less expensive when you consider what you get for your money. In fact, I’d guess that much of the software they’d need for today’s conditions could be had from truly viable open source sources. So maybe they could afford me, after all.
I was going to write a long-ass section detailing what I’d implement to handle which bits of the business, but I changed my mind. We all have an idea of what we’d do with this type of a project.
This is a response to comments that Jürg Meier made recently on something I posted a while ago. Jürg is a very smart and personable guy, whom I had the pleasure of meeting in person at ARMA Switzerland’s inaugural event on November 29, 2011. I urge you to check him out on twitter and here, where he works.
I was going to simply reply to Jürg’s comments on my blog, but I figured that the points he brought up are pretty substantial and would be of interest to a broader audience. I asked Jürg if I could paste his comments into a post and respond to them. You’re reading this so either: a) Jürg agreed; or 2) I’m in deep doo-doo.
From the original post: “Users know what business process they’re involved in. …”
JM: Chris, not sure here. What about knowledge workers, who “often advance the overall understanding of that subject through focused analysis, design and/or development” (Wikipedia). Are they in a business process? Perhaps, but more often than not in a very large one, like a product development, an IT or marketing project. These people send email, word and powerpoint docs back and forward, take notes. Notes? Karl Alexander Mueller, Nobel price winner in physics 1987, discovered a material for high-temperature supraconductors. He took the decisive note a few years earlier at a congress – on a single page of his pocket notepad.
Moreq2010 comes up with a similar example. In the introduction chapter, they show a hand written shopping list and the resulting cash register receipt. They consider only the latter as a record.
I would say that regardless of what the duration or intended outcome of a process is, it’s still a business process with measurable business objectives. Projects and cases (as in case management) cross multiple business processes and can be of several years duration. Product development takes ages, is complex, involves large numbers of people and huge volumes of content. However, it can still be tied to business processes and the participants (usually) know what they’re doing. In that type of scenario I think I would recommend using a case aggregation for the users to plunk their content into, and apply appropriate retention to the aggregate.
I would assume that Müller knew what he was working towards when he wrote the decisive note in his pocket notepad (how different is the pocket notepad from a tablet these days?). If my assumption is correct then it stands to reason that the note is part of the research documentation, which must be filed and retained. The big question in my mind is related to ownership of the intellectual property; does it belong to Müller, to IBM, or to both?
Another question that I have concerns an outcome that is unintended, but beneficial nonetheless. I’m sure we all remember what Sildenafil was originally intended for, and what its current use is. What, if anything, are the impacts on categorization and retention? Research & knowledge based processes are really tricky to deal with, but I think the key is that you can apply (business) rules & automation to the mundane aspects, use aggregations to capture the content, and let the participants do what they are engaged to do. I would certainly rather have medical / pharma researchers figuring out cures than worrying about where to file something.
The Moreq2010 shopping list / receipt example is analogous to an order / invoice example. Each document provides a part of the complete picture, and therefore is required. I also think that particular example is nonsensical unless for some official reason (e.g.: personal taxes) you need to hold on to the receipt. Frankly, I need to keep the list to prove to my wife that I didn’t bugger something up when she “let” me go shopping for her.
JM: In my experience, it is really a question of who will consume the information. There are the usual suspects:
– long-term (historical) archive
As you pointed out during your speech at the Swiss ARMA Chapter inaugural meeting, different people have different views on the same information. So, it would be compelling to classify information multiple times by different consumers… and I’m inclined to say: as late as possible. Only if we know about the purpose of the classification, we can do it right. E.g. for legal, they actually only know what they are looking for upon a litigation. By then though, they know very well what they need.
But what’s wrong with classifying as soon as possible, and adding additional classifications as they are identified, if that’s the case. The classification with the longest retention drives how long any content needs to be kept. This only works when classification and retention/disposition are segregated. In litigation situations simply applying a hold / freeze will do the job. There’s no reason to apply additional classification to the content because you create a legal case file aggregation and dump the content into it.
Content that has archival value, but no risk is easy – just keep it. I mean, I know we’ll want to keep all of my blog posts for the next 300 years or so. J It’s tougher when content that has archival value has some potential risk associated to it (privacy issues, legal exposure). I think at that point it’s really a judgement call. Frankly, I’m in favour of preserving because I’d like to think that sometime in the future there are going to be people that are interested in what we’ve been thinking and doing, and that the information they want is available. I’m also hoping that we’re not so stupid that we evaluate everything in terms of whether or not we’re going to get sued.
JM: However, the case of “late classification” does not answer one key question: for how long should we retain? The only reliable basis here is law and the retention schedule. And for that, by nature, we must classify upfront. That isn’t too difficult for “real business processes” (e.g. selling a ticket), but becomes tricky with output from knowledge workers. Here, to some extent, we need their support. Classifying draft/final is a good start, formally assigning it to a project would be very helpful, as well as identifying ownership and the document type.
For the most part I agree with this paragraph. For the knowledge workers, especially those that are involved in a lot of trial and error, I think we can come up with some reasonable classifications and retentions for them to use. Imagine how different things would be if the people that were working on Sildenafil tossed everything away once they realized they weren’t going to achieve what they set out to do.