[00:00:01] Speaker A: Hello, thank you for joining us. This is what Counts, a podcast created by Trailblazer Consulting. Here we highlight proven solutions developed through our experience working with companies across various industries and we talk about how you can apply these solutions to your company. We share our experience solving information management challenges like creating and implementing your records retention schedule, creating an asset data hierarchy, or helping with email management.
This is Lee and in this episode, Mora and I will continue to use our framework, Trailblazer Framework to talk about the devil in the details when it comes to applications.
Maura, take us away.
[00:00:41] Speaker B: Well, thank you for that invitation and introduction, Lee. The devil's in the details. So we are on episode five of our six. Five or six of our, okay, five I think of our framework. So our information governance framework, we've talked about it many times over the past 100 episodes or so and now we're to the final pillar of the framework. So if you recall, we have governance over the top infrastructure in the bottom, policy process, data, data content, and now applications. So we're going to do talk about applications today.
First question, when we were building this framework, you may remember, Lee, many years ago, which was why are we separating data from applications? Why did we make those two separate pillars? And coming at it from an IT perspective, the data is in the system, deal with it as one thing. Coming at it from a records perspective, the data has certain requirements related to IT in terms of retention and sensitivity, classification levels, purpose and use and context that are true regardless of what system it's in, even if it's in paper.
So we settled on, we need both, we have to address both these things. And one of the key reasons for taking the applications out into its own pillar and not putting it into infrastructure, because that was also a discussion like could it just sit in infrastructure? Because that's about it.
And we'll get to that one later. Why we, why we didn't do that, but why it lives separate from data is because all those things about your data, things about your information that are true, regardless of format, regardless of medium, regardless of system, the type of record it is, the category, the purpose, use, context, the sensitivity level, and what kind of protection does it need?
All of those things, the answers are different. Like those are the questions and the answers are different depending on the application that you're talking about, the system, the business app.
So we're talking about that kind of application, a software application of some kind.
Because if you are saving images in an image management system, then we're talking really about just the electronic form of paper and you apply classification rules and retention and disposition rules in a very similar way as you do to paper in folders or boxes, which is you tag the whole document or you put it into a folder, electronic folder, and you treat that folder the same way, or you put it on a external hard drive and you treat that external hard drive all in one, one way to do it. Used to be at some points in time we would have written things out to a compact, to a cd, a dvd, a laserdisc, depending on where in our history we're talking. And we would do that because certain regulations, as the world was making a transition from paper to electronic media, some regulations required that you write certain transactions on unalterable media. The SEC in particular had a general rule that applied to everything around trades that it had to be stored on unalterable media.
And in order to do that, that was a certain type of medium and it was a certain type of system that allowed you to get there. And if you ever had to delete that, which you would, because those records were not indefinite or permanent records, they had a certain life, even if it was a long time, you had to physically destroy that disk and you had to be able to separate out the other things that weren't ready for destruction. So those questions can be a lot harder to answer depending on the way your system is set up.
We were working in the financial world when we developed this framework and there were many, many old mainframe systems still around and transactions were written and they were, it mirrored closely the way that entries into a general ledger where you enter, you enter a transaction and then if there's a change, you enter a correcting transaction. You don't change the data, you, you can't change the data. It's not a relational database. Same thing that's very hard from a records perspective to apply retention or apply a legal hold. And there's been a lot of work done in the big enterprise resource planning Systems, the Big ERPs, SAP and PeopleSoft and some of the others to look at how can you take certain data out because it's met its retention period without affecting the remaining data? Because when you want, when you run a new report, it looks across all the transactions and it's challenging.
So the focus there on how do you apply these, this functionality, this record keeping functionality, how do you get it into your application so that you can follow your own rules, follow your own policies?
And for a long time I think there was, oh, we'll just keep doing the records part in paper and we will pretend that what happens in the system is just a convenience copy, but that doesn't really fit the principles of information governance, where the one you work with all the time, that's your record.
The extra copies that you put in a box and sent to a warehouse, those are not your records. They are not the ones that you are making decisions on. You have to depend on your system having the right data, having it be up to date and applying your policies there. Because if you have to produce information for an audit or discovery of some kind, that's where you need to go. You can't go to the warehouse. That's not going to meet your requirement. Not anymore. It may have 20 years ago when we were starting this transition, but it's certainly not true anymore. What do you think about that, Lee?
[00:07:23] Speaker A: Well, I think it makes it difficult for sure to be able to delete, let's say, a cube out of a certain system. And I think that's a specific term that's probably an SAP.
I don't know exactly, but anyway, I think so. I was working with a particular company that that's, that's what the whole job was. They were trying to figure out how to apply retention to SAP. And if they took the cube out, could they still create a report that held the information that they needed to replicate type of thing?
So I find it difficult. And I could see why somebody would argue that data needs to stay with the application. But I can also see your point of separating it for sure.
I think it makes it harder. I think people just want to leave the application and everything together and then sunset it and say, okay, we're done.
Let the whole system go away at the time retention takes place.
[00:08:28] Speaker B: It's funny that you say that because we have had many clients where the business says, we're done with this system, we need a new one because this one's not advanced enough, sophisticated enough. But, oh, just in case it, could you please hang on to this for us forever?
And so the IT department ends up with, you know, seven old accounting systems because they have purchased some other companies and they've got them sitting on servers and they're not, they may or may not be upgrading them. They may or may not be keep. They may or may not be able to keep them up to date without. Because those systems might not even be supported anymore, but the data is still in there. But you can't just write the data out because a flat file of data isn't going to be usable in the event that your accounting department has to go back and find something.
So what do we do about this problem? Because where in this devil is in the details? We're not supposed to just be complaining, although there's lots to lots to complain about around how systems work.
The, the truth is this is hard. This is going to be hard every time for a while. And the only way that I think we can tackle it is figure out what you do your records retention schedule. You do your information classification policy so you know what type of records you have out there. You know what your classification requirements are. You know your retention, your classification. You also know where in your ecosystem different types of data are stored. Which systems hold your employment data, which systems hold your mission critical data. That's part of that, your front end of the business.
So that when you have audits or discovery or some other need to go back in time, you're limited to a small number of systems. And then you need to look at your system development life cycle and your change management, your IT change management. So that when you put a new system in place, you think right then and ask the questions about okay, how are we going to apply our sensitivity levels, our information classification, how are we going to apply our retention requirements, which might be that active records are available for X years and they become inactive based on a certain event taking place, like the closing out of a contract, the end of an audit period for unclaimed property or something like that, the end of the audit period for tax returns. So we ask those questions up front before you put the new system in place. How are we going to do this? And if you're upgrading or changing from an old system to a new system, you also build that into your project plan for the new system. Your new system is not complete until you have handled your old data.
It's a, it's a mindset change and it means your projects take, may take a little longer, they may cost a little more. So then you have to look at this from a risk and cost perspective. Do you have a bigger risk of ignoring your data and just hoping that you never have to look at it for the 10 years that you're telling it? They have to hold on to it and be prepared that if you do have to look at it, it's going to cost a lot because at that point you're going to be talking to forensic accountants or discovery experts to dig in and resurrect the old operating system and figure out what's on with the data.
Or you could have to find the one guy who's the AS400 expert to go back in time, there's not a lot of them out there. Or do you say this data is important enough to us and we think we're going to continue to be asking asked questions about it or we're going to continue to rely on it and we need to figure it out now as part of the new project, how are we going to move it forward? So it's a cost benefit and a risk benefit analysis that has to be done around all your data in theory. But in practice you're going to look at what's the most important pieces of data. It's your financial data for sure. It might be your employment data because you have in many companies that's the highest litigation activity is in employment in the employment data. But it's usually a small volume of data per case. If you've organized things in such a way that you can find the right employee easily and not have to sift through everything, you also might want to look at where's your value? Like those are your risks. Finance and employment, where's your value? That's in whatever your front end is, your product work, your manufacturing, your designs, product safety. If you are in healthcare or medical devices or transportation or something else where you are providing, you know, the things that make our world go and you have a lot of potential product liability, you need to be able to find that data and make it available and accessible quickly and easily. It's worth the investment in the systems that manage that data to be able to apply all of your rules to keep that going. So it's a case by case basis. Use your principles, use your basic policies of retention and information classification and think about your business from a both value and risk perspective. And then you have to decide to make the investment.
That's still a high level view of what, what the details are involved in applications, but it's this, it's a, I hope a starting point on kind of what's the what, what is your thought process that you should go through around these things.
[00:14:36] Speaker A: That was good though. If you have any questions, please send us an email at
[email protected] or look us up on the web at www.trailblazer.us.com. Thank you for listening and please tune in to our next episode. Also if you like this episode, please be a champion and share it with people in your social media network. As always, we appreciate you the listeners. Special thanks goes to Jason Blake who created our music.
[00:15:03] Speaker B: Thanks everyone. See you next time.
