Yeah, that was too long for a title, but that’s how I feel right now. It’s as if my doctor had told me that “in order to remain healthy, you need to eat more Heath Bar Klondikes.” In addition, my new found happiness reveals one of SharePoint’s often overlooked strengths. Yes, if you want to, go get a Klondike before reading; it’s ok.
The project that I’ll be working on while my coworker and friends are in Vegas is one where we hope to link several aspects of our engineering process. To do this, we needed to refine an identifying number that has been in use forever. To really achieve that value we are looking for, we need a way to make it seem like this new way is the way we’ve always done things. The really cool thing is that SharePoint can make this all possible.
I’ve talked about bits and pieces of the neighborhood in which I’m working before, loss control inspection reports, recommendations and composite views of data. We have a solution that lets us track and support the development of a loss control inspection report. Ultimately, that process ends with the final report being stored as a PDF, in a records library – locked away forever. However, the process leaves the Word document that created the PDF, behind for review. Keep that in mind.
We also have a solution that tracks the recommendations our engineers make in those reports. These ‘recs’ have a long and complicated life. They get written. They get reviewed. Customers comment on them, engineering peers comment on them and once or twice a year, they get ranked:
- How important are they?
- How are they being addressed?
- Where are they in that life-cycle?
We built a series of custom lists to aid in this process. We also built a couple of composite pages, aided by some data view web parts to assist in that review. Still, something is missing.
What’s missing is the link between the reports in which the recs originated and the recs and the rec-review process. My job is to establish those links.
This is where ECM projects often run into trouble. We have hundreds of reports. We have hundreds of recommendations. Most of the recommendations are ‘closed’ but they still have value. A lot of information is coded into those custom lists, but the real value, the mother-load of information, is in the original reports. The trouble is that this isn’t a one-and-done process.
The recs can appear in many reports over time and any single report can refer to multiple recommendations. It takes time to review, reread, search and add metadata to those reports in order to link them to the lists…or does it?
Well, it seems that it will take some time, but not much. It also appears that going forward we can keep the reports and the recs in sync, with little or no effort at all.
The key to my happy day lies in the fact that SharePoint, with the aid of some workflow add-on products, can read those reports. Further, it turns out that the way our engineers like to write those reports, their “style,” the style they’ve been using forever, lends itself to being picked apart by Regular Expressions.
The reports already have metadata that tell us what policy they refer to. The recommendations have an ID number that tell us what facility they refer to. Today, I built another SharePoint custom list that links those facility ID numbers and our policy numbers. Now it looks like I’ll be able to have a workflow read the reports, pick out the recommendations and automatically maintain the activity in the recommendation lists. If this is successful, once an engineer finalizes a report, a SharePoint workflow will create a stub new recommendation or a stub recommendation update item, and then create a “please complete this item” task.
I’m talking in the future because I’ve only completed the proof-of-concept steps. I can read the reports. I can find the recommendations. I can build a new composite identifier and I can stick it in every custom list where it’s required. I usually wait until I have a solution to write about it, but this was so much fun, I needed to share it. When I finish this project, I’ll let you know how it works, in this blog and at AIIM14. If I fail or partially fail, I’ll write about that, too.