Joe Ales & Jason West
Season 2: Episode 6 – Integrations and Reporting
Jason West: Welcome to the Underscore Transformation Podcast, my name is Jason West.
Joe Ales: And I’m Joe Ales.
Jason West: And together, we’re the founders of Underscore. In season two of this podcast series, we’re focusing on the implementation and the challenges that surround making changes to policies, processes, systems, and team structures. If you want to learn more about Scoping a transformation programme, please take a listen to Season One.
In today’s episode we’re focusing on some of the more technical elements of transformation, and that’s integrations and reporting. This can be a challenging topic for functional leaders that are new to systems implementation, so we’ll be taking a ‘first principles’ approach to our discussion today.
So, Joe you’re never one to shy away from a conversation about integrations; what do our listeners need to know? What’s an integration and what on earth has it got to do with reporting?
Joe Ales: Gosh, you’re making me sound like a little bit of a geek here [LAUGHS]. But I am quite passionate about this, because, actually, one of the reasons these this is so important is the impact it has on the overall programme: on your overall success of the programme.
Jason West: Yes, and the overall success of the function, once the programme’s rolled off and gone into the business.
Joe Ales: Yes, absolutely. It’s so, so critical and many organisations probably don’t pay enough attention to integrations and reporting early on. But to answer your question: what’s the difference between integration and reporting, I mean I am not a technical geek, just putting it out there, but having done a few of these I can take a stab at it. They are both about transmitting data. Integration is point to point, it is something that is transmitting data that updates a separate system: computers talking to computers, with hopefully a bit of a human in between, creating some sort of logic in terms of what data needs to go across from one system to another. And reporting is data that is presented to a human. It’s something that’s probably used in an organisation, and at sometimes there’s reports can be used as well to update other systems. But the point is that you’re delivering a piece of data to someone, for that someone to do something with. And in all cases, in both cases actually, whether this is integration or a report, you need to be very, very clear in terms of what data is required, what’s it going to be used for, particularly in the context of the GDPR and data protection, and so on and so forth.
This has become much more important than perhaps it had been in years gone by. So, how are using it? Why use it? Who’s seeing it? Who has access to it? Etc. You need to have a real clear rationale as to why that destination system needs whatever data it needs from the system of origin. And then there’s all the technical stuff about formatting, and making sure that you very clear, in your specification, the formatting needed in a destination system and how frequently do you need to send it. These are some of the very, very basic questions you need to ask, at the very outset. And then, of course, as you start going into more and more detail later on in your design, the questions might become a little more complicated.
Jason West: Yes, so we will keep that very high level for now. So, we’ve defined some terms: integrations are a way of way of transmitting data from computer to computer, and reporting is the means of transmitting data to people.
With those terms defined, let’s talk about integrations first and then we’ll get on to reporting. For somebody that’s leading a transformation programme, or perhaps sponsoring a transformation programme, what are the key things they need to know about integrations from the get go?
Joe Ales: If we first define ‘from the get go’ – ‘from the get go’ is way before you signed a contract. You really need to have understood, when you’re scoping out the transformation and you’re trying to push in a system, what’s this what’s this system going to talk to? Who is it going to talk to? You’ve got to have clarity around that.
Jason West: You should have a set of assumptions that you’ve made during the scoping phase about what this new system is going to do, and which other systems is going to talk to.
Joe Ales: Yeah; what functionality are you going to bring in? What legacy systems are you going to replace? For the system that is is going to replace, what does our system talk to right now? Are you creating a new set of data structures as a result of your new system coming in, that actually the legacy system didn’t speak to before? All that sort of stuff that you really, really need to have a nail down. Involving the IT function in this space is really, really important; systems architects, data architects, making sure that you’ve got your master data set up. And I will probably touch on master data a little bit later on, because again, that’s a really important decision that you need to make, which is where’s your data going to be mastered, etc.? And then there’s a whole load of technical stuff, as well, around are you going to have middleware, hardware? How’s it going to get transformed from one system to another? It’s really, really complex stuff, and the point here is you cannot allow this to be an afterthought in your programme.
Jason West: You’ll be carrying a massive amount of risk if you start implementation and you’re still figuring out what your technical team’s doing, or figuring out OK “is this system going to talk to that one? Is there going to be a bit of middleware in between?” The costs will just escalate rapidly if that isn’t fully scoped out before you start implementation.
Joe Ales: Absolutely. I mean, things will iterate right through your implementation, but it shouldn’t be a surprise that you need to integrate to another system during your project. It shouldn’t come as a surprise to anybody. If there are data sets, because there’s a new system that you’re sending data from, that doesn’t have a particular data set that the other system requires, you need a solution for that. But there should be nobody saying “wow we need to integrate into that system over there? I hadn’t thought about that. Let’s now start scoping out design of it, whilst we’re making a whole bunch of decisions around how’s your TOM (Target Operating Model) going to work? How are your processes going to work? How’s your data going to be handled?”
Because all of those decisions, you might have already made during an earlier phase of your implementation, and an integration requirement comes along that might impact on some of those design decisions you’ve made. And you really don’t want to be doing that.
Jason West: Yeah. In fact, that often happens, doesn’t it: you’ve done your best, during scoping, to engage across as many people as you can to gather their requirements, and understand what their wants and needs are. But when you actually kick off one of these programmes, it’s not unusual for people to come out of the woodwork, and go “ooh, that new ERP you’re putting it in, that new system, it would be great if you could store this information. I just need to pass it across to you.”
And there’s a really good reason for doing it. You look at it and think “yes, that will add a massive amount of value.” But you’ve just got to be careful; do you want to put that into your phase one go live and add a new integration? Sometimes, you may, and it might be a business critical element, and there’s good reason to do it. But wherever possible, try not to do that. Do it, but not in the first phase. Get it up and running after you’ve gone live and everything’s embedded in; adding additional integrations during implementation is a risky business.
Joe Ales: Yeah; scope it out during the scoping phase, and, as you already mentioned Jason, in our intro, about listening to season one, we talked about this already, in season one. Getting your assumptions right. Do the groundwork before you start implementation, and before you get the system integrated in the room, because, guess what: a new integration is additional cost that hadn’t been scoped out before, that hadn’t been included in the statement of work, and hadn’t been included in the contract of deliverables from system integrator. So it’s going to be additional cost. It’s something that had been planned for, in terms of your resources, in terms of technical resources to do to the build and testing etc. Surprises like that are reasons why project schedules get delayed, so it is really, really important that there are no surprises.
Jason West: Yes, because this is one of the riskiest areas anyway.
Joe Ales: Absolutely, scope creep in integrations is definitely up there, as one of the main reasons for changing scope of the project. Actually, sometimes it’s taking integrations out of scope as well, because it becomes a little bit too difficult. And I’ve seen projects where integrations have been taken out of scope, but they were so fundamental to business case being achieved. So, it’s like “why are you taking that integration out of scope as you’re going to get so much value out of it?” It might be complicated to deliver, but you shouldn’t really be doing that. When taking integrations out of scope or putting them into scope it needs to be really, really carefully thought through.
Jason West: Yeah, I think you said you tend to get that more where you’ve got a very technical project manager, that is just looking at their world of lots of technical risk about getting this live, without it being fully tested, and all those sort of very sensible things. But, because they’re technical, they don’t understand the operational impact of taking this particular integration out of scope.
Joe Ales: And now you’ve got your keys, and you’ve got all of our sort of all of that to deal with. How are you going to keep two systems data synchronised? Integrations play a vital role in that. So putting integrations into scope are equally as bad as taking integrations out of scope.
Jason West: Absolutely, and I think this is where the governance structure in your programme comes in. And surprisingly enough, we’ve talked about governance before, and we’ll talk about it again. But you need these multiple lenses as you look at any one issue. It’s fine for a technical project manager to make an impassioned argument for pulling an integration out of scope, but you need a programme manager sat above that, you need a transformation leader sat above that, you need the sponsor being really clear about “well actually, this is the benefit that we need to deliver to the business”. And to look at it through those different lenses. Whilst it might be a good technical argument, it’s actually the wrong thing for the business.
So, the other area where technical project managers can present, perhaps a slightly over optimistic, approach is to their state of readiness of their various integrations. And that can be a bit of a challenge for a transformation lead, that’s new to the role, or a sponsor that hasn’t perhaps sponsored a major system integration, or system implementation before. What are those key questions that you can ask to make sure that your integrations are really ready?
Joe Ales: “Has it been designed? Has it been built? Has it been fully tested? Give me evidence of the tests that we’ve executed, what scenarios have we pushed through the integration” If you’re starting to hear, quite close to the a go live – and it might be two or three months away that’s quite close to a go life; ‘close to go live’ isn’t the next week, ‘close to go live’ is two to three months – and if you start to hear things like “well the integration is going to be built next week, or the week after” you start to question whether you’ve got enough time to put enough data through, to do all of the testing that you need to do. Because a lot of these integrations rely on data being processed in a certain way. So if you’ve got a purchase order account or an invoice, you need those invoices to be processed in a certain way, to give you the data that you need, to end up in a different financial accounting system, for instance. You need to give yourself enough time to put an awful lot of processes through, and if you’re starting to hear that “the integration is nearly ready”, two or three months away, I would I would start to become a little bit nervous.
Jason West: What wants a sensible time frame, then, to build, test, or design, build and test an integration?
Joe Ales: It’s kind of ‘how long is a piece of string?’ It depends on the complexity. But you’re going to have different iterations of it. You’re not going to get this thing right first time. You’re going to come up with issues, either data issues, the formatting, the way the system is processing some transactional data, that’s not easily transportable to a different system, or not easily transportable in a way that the destination system expects it. You’ve got to account for all of these nuances that you’re going to get. And then the other thing is making sure that you’ve got things like your development environments ready to test these integrations. Very often, it becomes a bit of a surprise that we need to test integrations, and there are no development systems, of that destination system, to test them in. So it does present an awful lot of problems, and issues, and many, many projects I’ve seen have pushed out integrations post go live, and that gives you no end of issues when, as I’ve said before, you’re trying to keeps two systems synchronised.
Jason West: So, you mentioned test environments of downstream systems. This is a copy of that that operational system, in a test environment, that you can then link your integration from your development environment, of your new system into that test system. So, the other thing that you touched on was design, and I think it’s really important just to focus on this a little bit here. What are the key things that the sponsor or transformation lead wants to reassure themselves around the design? What are those questions they should be asking, to make sure that the design is in a good shape?
Joe Ales: First of all, make sure that you’ve got a technical architect working on your project, someone who understands design of these integrations. And ask the technical architect “where are we with the design? Where are we with the data? How’s data being mastered?” Get another point of view. Another critical point for integrations is data quality. “What’s the quality of our data in our legacy systems, that we are moving across into our new system, that’s now going to be used to push data out to other destination systems?” Really, really question that data quality.
Next, where are you in the plan? How far away are you from go live? And if it’s two or three months, and if you’re still in design mode and you’re not yet testing, if you’re still trying to figure out what the specification should be, be worried. At this point, two or three months out is not a long time away, and the sponsor should start to feel comfortable that we’re in test mode of integrations.
Jason West: You touched on something there around master data management. It’s something that gets spoken about a lot, and it’s not actually all that well understood. So, it would be good to get a bit of a 30 second overview of master data management.
Joe Ales: I’m starting to sound like a technical geek, but I’m not, I promise you. I’ve just done enough of these projects to get a vague idea of what this is. But for me it’s quite simple. There’s an awful lot of master data management specialists out there, with lots and lots of know.
Jason West: Please write if you are a specialist.
Joe Ales: Yes, please let me know if I get this wrong. But don’t slam me for it. For me, simplistically – and I am going to get slammed for this I’m sure- but simplistically it’s ‘where is data mastered?’ And making sure that you’ve got the definition of that data set well-articulated. Make sure that you’ve got things categorised, so that you’ve got your data security tied into it as well. And in my simple layman terms, that’s what master data management is.
Jason West: And when we say ‘mastered’ we mean where is it created.
Joe Ales: Yes, where is it created? Where do I find that one version of the truth, that I need to get at? If you’ve got headcount being mastered in two separate systems, guess what is going to happen; you’re going to have to check both of those systems to get to the one version of the truth.
Jason West: And if you’ve got part numbers, are you really clear on which system is creating those part numbers, and the format of them, and is it the same across all different systems?
[LAUGHS] please don’t start talking about master data management and part numbers in Excel or we’re going to lose everybody.
Joe Ales: Don’t worry, I’m not [LAUGHS].
Jason West: OK, so your design you’re pretty confident about, your enterprise architects have been involved in the overall design. You touched on the fact that if it’s two to three months out, and the integration still haven’t been built and if you’ve got a programme of say 12 months, where implementing a new system is going to take you 12 months, I can see two to three months towards the end of that that could be really worrying. When would you expect these integrations to start being built in that kind of 12 month programme? And when should a sponsor start getting concerned if there is still stuff not built?
Joe Ales: I mean, you obviously can’t start doing integrations from day one, because the data set doesn’t exist in the system that you’re trying to build yet. So you need to have your integrations well specced out during the very early stages; as soon as a system integrator is standing in front of you, asking for specifications, you need to be able to provide those. You then go through the initial phases, and especially with cloud technology, it’s iterative so you have your first prototype, and where you are starting to build, to push some of your data into that prototype, and you start to make some design decisions around process after that. At that point, you should start to build your integrations. Once you’ve got some data set in there, you should start to build your integrations quite early on. So maybe two or three months to go, the first iteration of integrations would be built. Then it gives you runway of four/five months to test some of this complicated stuff.
Make sure that you’ve got your test systems, like we talked about before. Make sure that once you’ve got your integration you know “How do I send it? Where do I send it to that destination system?”
Jason West: Who owns that destination system? Have you identified the owners of all these systems that you’re integrating with? Have you spoken to the supplier?
Joe Ales: In all of these things there’s an element of: you need to get your yourself into a state of readiness, before you start getting head down into designing integration. You need to have done quite a lot of groundwork prior to that, so during that initial phase where you’ve got your first iteration, first prototype, being built, use that time and your integration leads or integrated systems architects etc. to make sure that you’ve got all your ducks in a row. All the destination systems you need to integrate with are expecting that data set to be sent across, and into what systems etc. Use that time to prepare, and then once you’ve done your first set of integrations, then you really ready to kick some some testing off.
Jason West: Yeah, so if you know before you start talking to them about this sort of level of detail, hopefully they’re aware that this programme is happening; you’ve involved them in any kick off meetings, when you look at those target systems that you’re looking to link up with, you’ve identified not just the person in IT that owns that system, but also the business owner. The person in procurement or finance or sales or whoever you’re linking in with, you’ve got that business owner engaged in the programme. And you’ve really thought about how you’re going to involve them in your governance structure, because they’re going to have to sign some stuff off before you push an integration live, so you’ve got to have thought that through. As a sponsor, just making sure that those sorts of things have been thought about, and documented, and that you’re confident that you’re getting the right sort of answers back. On that timeline piece, if you’re not getting satisfactory answers to these sort of questions, and you’ve already started designing the detail of new systems and new process, you should be concerned really.
Joe Ales: Yeah; integrations rely on data being processed. If you have not done that integration design in conjunction with the processes that you’re designing, you’re going to carry some risk.
Jason West: So, including your system architect, your integrations lead in those process design workshops is absolutely vital.
Joe Ales: Completely, because you’re designing end to end processes. You’re not just designing the functionality within wherever system you’re building. Or you’re designing end to end process, so how data is designed. And sometimes, data can travel between two or three systems.
Jason West: I can actually think of a project that we went in to have a look at and turn around, and the IT function and the system architects had been deliberately kept out of process design workshops. It was not a good outcome. This is an integrated programme team that you need to deliver this. This isn’t one function going off and doing its own thing. If you don’t have your IT function fully integrated into your programme team, you will have problems.
Joe Ales: Many projects might actually take a simplistic view that “well I’ll just replace whatever integration we have today, with a new set of a new integration from the new system”. However, data is going to be processed differently, and the data will be different – we talked about master data management just a second ago – that’s going to be different, it’s going to be catalogued differently, the security model around the new system will be different. So, you can’t take a simplistic view of “OK, today I provide this data set, on a Monday it has these sets of five or six data values, and I’ll just push that out again from my new system of record that’s coming in”. Don’t take a simplistic view of that, because actually, there’s bigger opportunity, potentially, to optimise your end to end process further if you take a more holistic view of your design.
Jason West: We’re not saying that won’t work. It will work; if you say “we’re were going to replicate that integration” you’re going to get the data in exactly the same format, exactly the same frequency. It’s just a missed opportunity isn’t it; you could fundamentally redesign that that end to end process so it works better in the long run.
Joe Ales: Yes, and if there are some conditions in your business case that you can optimise, you’re going to simplify your processes, and integrations play a key role in that. And if the answer is, after you’ve done the review, after the systems architects have been involved, and not kept in a darkroom, if the systems architects, data architects have been involved and everyone thinks that the most sensible thing to do is to just do a ‘lift and shift’ absolutely do that.
Jason West: Absolutely, but it has to be a considered and informed decision.
[intermission]
Jason West: So, we’ve got our integrations well designed, they’re fully specced out, the technical team are well on their way to getting the build done, we can just park that for a minute and focus on reporting.
What is the link between integrations and reporting first up?
Joe Ales: Well, integrations are complex beasts. You’re pushing data from one system to another, reports are sometimes a bit cheaper to produce. And probably a lot more flexible as well. Many projects actually confused the two. They receive a monthly costing report that they think is an integration; that’s just a report. You might be updating the system, maybe through keying, or whatever, with that data set, but that’s just a report. Another thing to consider around reporting if we actually step away from integrations now, if we think about reporting, is what are those reports you need to effectively run that function? Or that process? Making sure that you’re being compliant; that the policy that you’ve designed is being adhered to through the processes of the technology. Reporting is really, really important, and the amount of projects that I go into, or to review, and they’re not considering reporting at the very outset, is shocking. Reporting is a real afterthought for many. Because of the idea that these new cloud systems come with ‘out of the box’ reports, with thousands of reports; “surely there’s one in there that we can use”. There may well be, but you need to document, you need to create your reporting strategy right up front. Because actually, one of the other things it will do, it might fundamentally change the way you design your processes, or the way you structure your data sets within the system.
Jason West: If you haven’t started from that place of “well what are the decisions that we need to make? Who’s going to be making those decisions? What information are they going to need to make a well informed decision? And then what format do they need to be? How frequently do they need the info?” It is very similar, as we said at the start, to the integrations piece, it’s just it’s that human element of it.
Joe Ales: It drives security; again, if you expect your execs to make a set of decisions on some financial data, human data, HR data, they need to be able to see it in a way in which they expect to see it, to make those solid key business decisions. Because that’s been the premise of your business case. Your business case has been probably built on the fact that we are now going to have data driven decision making. And if you don’t think about that right up front, you end up with a system that’s just purely a transactional system, that’s processing data. It may, at the end, give you out some dashboards, but it’s probably not what you envisaged when you created the case for change at the very outset.
Jason West: And we’ve seen it on more than one occasion, where you’ve made an assumption coming in, that people will be making these great data driven decisions, and because that design work around the reporting hasn’t been done, a fundamental data set just wasn’t put into the new system.
Joe Ales: Or a security model hadn’t been thought through, to allow individuals to see the data they need to see. The processes just haven’t been built to actually transact the data in the way that enables those reports to be created, and presented, in the way they need to be presented.
There’s an awful lot of thinking that needs to go into reporting at the very beginning of the project.
Jason West: Yes, so you’ve got those strategic reports, those business reports. Actually understanding what is the, probably very large number, of reports that we produce today from our current systems? And doing a bit of an audit on that, and understanding world would probably got 15 different versions of the same thing, they’re all slightly different colours and slightly different columns, in slightly different order because that’s just what happens over time as things just get built on. You need to understand what the requirements are today. You’ve [Joe] touched on operational reports, around how are we actually delivering our processes, but what are the other things that you need to consider when looking at reporting?
Joe Ales: Data quality. You’re going to have an enhanced data set in the new system, that you’re putting in, that you didn’t have in your legacy system before. Wherever data quality you had before, that was appropriate to the system that you had before, it’s not going to be appropriate to the system you’re going to have, because it’s a fundamentally different set of data.
Jason West: Especially if, and I assume this would be the case in most business cases, you’re going from a heavily centralised data entry to a broader data entry, through self-service. If you haven’t really thought through the restrictions you’re putting on the way people are entering data into your system, there’s a good chance you’re going to go from something that, actually potentially had quite a high quality of data, because it was a well-trained centralise team that input data, and they knew all the nuances of this system that you had. Compared with today, where you’ve just gone live with a brand new system, that works completely differently, but you’ve pushed a lot of that data entry from the centralised team, out into the wider function, or out into the business. You can expect your data quality to actually decrease initially, and there’s a very good chance it will. No matter how much training you do, no matter how much structure you put around it, it is not possible to know everything. You might find that over time you need to start adding in mandatory fields, or input masks.
Joe Ales: Yes; think of that right up front in your design. If you’ve not thought that through, and you’ve gone live, and your data is in right state, it’s not a good place to be. So think through that as your processing that data set, you need to think “what are the critical data points we need to be right?” But don’t overcomplicate it either. There’s a balance here. I’ve seen cases people of people too fascinated with things that are sometimes quite simple. Just take a sensible approach to make sure that the user experience is right, and not overly complex and burdensome. And the more rules you build into a system the more difficult it is to maintain it. So it has to be a balanced decision.
Jason West: I think the important think is, as you say, design as much as you can up front, but you really cannot design for everything. You need to have those data quality reports, operational reports, audit reports, compliance reports, to make sure that once you are live, you can see how the system is actually being used ‘out in the wild’. You need to review them regularly, and update the design of the system in real time, to get you to the position where you want to be. Which, in most cases, is devolved reporting capability out with the people that are making the decisions, so they make the best possible informed decisions that they can. And for them to do that, they need good quality data, they need data in the right format when they’re making the decision, that they trust. And that takes time.
Joe Ales: Yes, and we talked a bit about this in integrations, but you don’t want to compromise the quality of the data that ends up in a different destination system. So you’ve gone from a world, like you said before, where everything is centralised, everything is controlled, the data entry is executed in a controlled way by a centralised team. Now it’s in the Wild Wild West, with everybody having access to their own self-service data. Not only are you compromising the quality of data in the system, but actually, you’re potentially compromising the downstream systems that you’ve integrated with. You spent forever creating these complex integrations to push data from one system to another, and now, all of a sudden, you’ve got a bunch of enterprise wide systems, that are totally knackered. So data quality, data structure, reporting, audit, governance – all of that – think through of all these points and get it right up front.
Jason West: I think the point to leave people on, is that, from a reporting standpoint, you’re going to build as much as you possibly can before you go live. And that’s going to be as well designed as it possibly can be, but the reality is that your brand-new shiny system hasn’t got much data in it. So that business case that you put together, that said “we’re going to make this wonderful data-driven decisions, that were going to get better outcomes because of it, and all of the financials that are going to flow from that” it will take time.
Joe Ales: It will take time. And we don’t like seeing business cases that expect immediate ROI on day one, that assume that as soon as you’re live, you’ll start getting benefit. You won’t. You need a good amount of time to have data being passed through.
Jason West: Yeah, absolutely. And that’s probably one of the questions that you need to ask as a sponsor or transformation lead: “what is our strategy, our plan post go live?” As we said, on many occasions, day one is the beginning. Go live is only the beginning of the journey, it’s not the end, or even the delivery of anything. It’s just when the change starts. So being really clear on “what is that plan? How we going to roll out new reporting, new functionality? How do we get to those predictive analytics that everyone is very excited about? How do we get to machine learning?” Actually, machine learning is complete waste of time if it’s based on a messy data set, you are going to get some very, very bad outcomes if that’s the case.
Joe Ales: Imagine CEOs, CFOs etc. making strategic decisions on poor quality data; it’s not a good place to be in. And you don’t the exec to be questioning whether they are making solid business decisions on the data that’s been presented in front in front of them. You need to have your robust processes and practices built in as you’re building your project, as you implementing. Put those practices straight into the programme from the outset, to give everybody confidence that everything within the system integrations are working, the data is good quality, people can see what they’re allowed to see.
Actually, one of the things we didn’t talk about, too much, is around data security. Pay a lot more attention to that than perhaps you had done before, and one of the key things to consider here is yes, you’ve got an amazing security model in the system that you’re implementing today, you’re now pushing data to a different system. Ask the question “who can see the data that I’m sending across to that system? What security model does that system have?” Be really careful and make sure you think through “I don’t want people to see XY&Z”. Yet, all of a sudden on integration those individuals can see XY&Z in the destination system, is not good place to be. Get your system architect, who was doing that design, describe to you as a sponsor, who can see what data across all of our systems? And nowadays, with data privacy legislation changing all the time, it’s more and more relevant.
Jason West: So we’ve skimmed over a very, very big topic here. And I’m sure we’ll do a dedicated podcast later on, one on integrations and one of reporting. They are both actually really big topics in their own right, but just as a bit of a recap, we’ve started off with some definitions: what is an integration and what is a report?
Joe Ales: We’ve described master data management, which I am going to get slammed for.
Jason West: Yep, I’m looking forward to that. So all of you data architects, contact Joe over on LinkedIn and just let him know where he’s gone wrong.
Joe Ales: Yes, I l look forward to having to change my profile [LAUGHS]. They’re very passionate about it – rightly so – and we’re probably undermined it somewhat.
Jason West: We’ve talked about the things to watch out for, in terms of the design, the build of integrations, the timing on that, and some of those kind of key questions that you can answer as a sponsor, or a transformation lead, on getting a degree of comfort that your integrations are on track.
We’ve talked a lot about reporting; how to structure your reporting architecture, the different types of reports you need to think about, and the real importance of including reporting design right at the very beginning and thinking that through very carefully. But also a dose of realism, that in reality, your business case is predicated on data driven decisions that aren’t going to get made for the first few months, maybe even the first year or two. Because you need a chunk of data to see trends and get the insights you need.
So, next week we’re going to be talking about data. That’s a couple of really technical episodes for you, and then will be back into governance, after that, and all those sorts of topics for delivering a successful transformation.
Joe Ales: Thanks for listening, we really appreciate your support. This episode focused on one of 10 critical success factors in the build phase transformation. If you’d like to be the front of the queue for next week’s episode, please hit the subscribe button and don’t forget to like our show if you found it useful. If you have any questions or opinions you’d like to share please contact us: Joe Ales or Jason West on LinkedIn, or via our website underscore-group.com.