Episode Transcript
[00:00:00] Speaker A: Hello and welcome to what Counts. Every organization hides a story in their data. This is a podcast that digs into the governance problems people inherit, ignore and discover too late. I'm Lee and as always, this is my co host, Maura Dunn.
Maura, last episode we ended with you saying he wanted to come back and talk about creating data as close to the source as possible.
He said that data that supports business process should. Process should sit with the business process. What does that mean exactly?
[00:00:35] Speaker B: So the, the idea here is that the more changes that data goes through, the more hands it passes through, the more times it gets copied and shared, the harder it is to be sure that it's that you follow the provenance, you followed the chain of custody, the you know that the data is reliable and accurate.
We've been talking for a few episodes now about making sure that your data is reliable and accurate. That that's the kind of the key to success. If you're going to use your data to feed AI tools or automated business process or anything, you need reliable, accurate data. You also need timely data that you can find.
Those are different issues, but starting with that reliability and the accuracy. So if you think about when you're, when you're doing something, you're writing, you're writing something brand new, you've never done it before.
So we, over the years, we've developed a lot of new things. We developed a way to, a way to associate data in systems with litigation profiles for our customers.
So we look, do it kind of baseline inventory. Where is your data sitting? Is it in repositories? It is in databases, is it copied? Is it cloud based with all the different things that you can find pretty easily by running some tools against where the data is on your servers.
But it doesn't tell you much. It tells you that it exists, might tell you how much there is, maybe it tells you a file format, but it doesn't tell you a lot else.
So we developed approaches. We developed first an approach for what we called backfile characterization. And that approach was, let's look at the folder structures at the very baseline, very first thing, how's the data organized?
So when we were developing that approach, we were the, we were creating it and we were documenting our process because we wanted to keep track of the steps.
So if we had not done that, if we had created that process, but we didn't document anything, and then we just turned a report over to our customer, you know, three weeks later, here's what we think about your data. You should dispose of this you should keep this, and you should put these things under your retention schedule and keep them for X number of years.
But we didn't give them any of the how. We didn't tell them anything. So we did some work. We didn't document anything.
And then they have a report that says what they should keep and what they should get rid of. It's not very defensible because they didn't, they didn't capture what happened.
[00:03:29] Speaker A: So you didn't show your homework, right?
[00:03:33] Speaker B: A lot of records management and information governance is about showing your homework.
That is the, like, that's, that's the difference between content and context.
The content is that report at the end that says here's 75 files and you should destroy 60 of them, keep five of them for a year, and then keep the other five forever, whatever it is.
But, but with no, with no process behind it. If somebody came along the next year and said, why did you destroy those 60 files? Our custom. Our client would have had no answer for that. Oh, because Maura said so, right? That's not a good answer.
That's not an answer that Maura wants to have out there in the world. So instead what we did was we documented the whole process and we said, here's how we determined that these files were ready to be destroyed in accordance with your retention schedule. And how we did that was we looked at the properties in the files, we looked at the folder structures, we looked at the dates on them, how when were they created, when were they last modified. We looked at which part of the organization had created those files in the first place and which part accessed them. We did that by looking at security groups and access to folder structures, because all of those pieces come together to say we have this level of confidence that these records are, would, would align with your sales and marketing record category. And your sales and marketing record category has a trigger of end of fiscal year plus and a retention period of five years. And so this is our confidence level based on the data we collected about your documents and the, and the rules that you've created in your retention schedule.
And then providing all that information gave our client something to react to. And then they make a judgment, what's the risk? And that depends on how high is your confidence level that we provided based on the data we collected. And we did the same thing for paper records when we would look at, as you know, you spent a lot of time looking at tens of thousands of boxes that have been sent to off site storage with varying degrees of useful information sent with them.
Maybe they had a retention schedule attached, maybe they didn't.
And we would do samples and go actually look at documents and things like that. So I'm describing how we created a process and the closer we were to that process, we created the records that described the process that then our client could depend on.
So that's a situation where we created that data close to that business process instead of doing it after the fact and removed. So it's the same thing for every business process.
Instead of capturing it at the end, you capture it along the way.
And we incorporated that into our records process mapping approach where we help, we take typical business process engineering steps that any good consultant will do to help a company look at their business processes.
But we also note at this point in the process, we have received a new input and it is going to be a record because we're going to. The process is going to act on it and make a decision and make changes.
So that's a records capture point.
And at this point in the process, 17 steps later, we've changed that input. We've created something new that is another records capture point.
And it's. And it's right in the business process again, instead of waiting until the end.
And this is something that is, I think that was not able to be done and not really needed to be done when, when process wasn't automated and when information was mostly captured in paper.
Because when you think about a process, when we first started, when I first started anyway, working with the. The US EPA was the first client that I had. Actually, no, the US Marine Corps was the first client that I had. But the US EPA was the first one where I really was diving into this level of work. It was a long time ago. And they were creating, in the Superfund program, they were creating SIT reps. And the SITREP was a written report, a situation report where someone would go out, a scientist, an engineer would go out and evaluate the damage that had happened at a site where there had been waste abandoned.
And they would look at it, they would take samples and they would do their own analysis. And then they would write a memo, a sitrep, a situation report, which was captured in paper.
Even if they, at the beginning they were writing them on typewriters. But at least that I'm that old, that's not true.
They were just out of the typewriter stage and into using word processors.
But the result, the record was a piece of paper with possibly actual output from sensor machines, from the gas chromatograph. My favorite machine and they would have a printout that came from the machine and they would have air sample, air quality samples that they got from a different machine. And they would have a written report, a typed up report, and it would all be in a folder. And they had hundreds of them in drawers in each regional office of EPA for the Superfund program.
And so their process, their process didn't produce interim record steps. It only produced that report at the end. And so then you captured that report and, and you saved it in a drawer and then eventually you sent it in a box to the Federal Records Center.
But process today is manipulating information in digital form throughout the process. And that's why we have to capture it multiple times. We have to capture it along the way. So that's what I'm talking about of capturing the records close to the process where they happen.
[00:09:59] Speaker A: Capture it early and before, I guess before it has a chance to get manipulated too many times.
[00:10:10] Speaker B: Well, before you've lost track of what happened to it. Yeah.
And the beauty of an automated workflow is you can build those capture points in and you can see the changes document management systems are made for version control.
So you can see, here were the comments, here were the collaborations, here were the edits. You can keep those things. Now, do you have to keep all those things? Maybe not. That depends on your retention schedule. But your process will allow you to build in the places where you need to capture it, which are the major points. Here are my inputs. Here's my interim decision support draft that's going, you know, if you're in the government, it might be going out for comment. If it goes out for comment outside of your office or outside of your agency, then there are laws that, that regulate how, that you must keep those comments, whether you incorporate them in the final draft or not. If you are subject to public comment periods, you have to prove that you got the comments and that you responded to them and then you have the finals. So it does depend on every business process. What are those capture points?
But the principle of capture the record close to the place where it was created goes across all of them.
[00:11:33] Speaker A: Okay,
[00:11:37] Speaker B: so because I just, I want to, I want to take one step back because the reason we're saying this, the reason we're doing this is the point of records is to provide evidence of what happened. And if you only have that last thing back to our backfile characterization report. If you only have the report, you don't know what happened, you don't know how you got to that report.
You have to capture the process that got you there. So that principle applies everywhere, across all of the.
All types of business process, all type of types of records.
It's just in some ways it's easier to do it with automated workflow. In some ways it's harder to do it because the volume of information just keeps growing and you have to wade through it and decide, I'm not going to keep it all. These are the three things that I know are important. These are the three points where I know it's important that we capture what's happened.
That takes discipline.
And that discipline is the same as that business process engineering discipline from 50 years ago or even longer.
So that's my story.
[00:12:49] Speaker A: Okay, that's good.
[00:12:51] Speaker B: That's good. That's my story on capturing records when they get created.
[00:12:56] Speaker A: Okay.
Are we good with this version?
[00:13:00] Speaker B: I'm good. You haven't said anything. Do you have any questions?
[00:13:02] Speaker A: I don't have any question. I mean, it's pretty logical. I was, I. We could go through another example that's more recent if we wanted to, but I think.
I think it's pretty clear.
[00:13:14] Speaker B: All right, then. Until next time. We'll see what we talk about then.
[00:13:19] Speaker A: If you have any questions, please send us an email at info trailblazer us.com or find us on the web at trailblazer blazer us.com www.trailblazer.us.com Check out the Learning Academy at trailblazer learning academy.com that's also important.
Thank you for listening. Please tune into our next episode. If you like this one. Please be a champion and share it with people in your social media network or like or subscribe. That's always helpful and we appreciate you, the listeners. Special thanks goes to Jason Blake, who created our music.
[00:13:57] Speaker B: Thanks, everyone.
