 Hello and welcome. My name is Shannon Kemp and I'm the Chief Digital Manager of DataVercity. We'd like to thank you for joining this DataVercity webinar, New Year's Resolution, Improved Team Communication, sponsored today by IDIRA. Just a couple of points to get us started. Due to the large number of people that attend these sessions, you will be muted during the webinar. For questions, we will be collecting them by the Q&A in the bottom right-hand corner of your screen. Or if you'd like to tweet, we encourage you to share highlights of questions via Twitter using hashtag DataVercity. As always, we will send a follow-up email within two business days, containing links to the slides, the recording of the session, and additional information requested throughout the webinar. Now, let me introduce to you our speaker for today, Kim Brushaber. Kim is the Senior Product Manager for ER Studio Business Architect at IDIRA. Kim has over 20 years of experience as a business analyst, software developer, product manager, and IT executive. Kim also enjoys working as the translator between the business and the technical teams in an organization. Perfect speaker for today's topic. So with that, I will give the floor to Kim to get today's webinar started. Hello and welcome. Hi there. Thank you so much for having us. So I'm going to start this out with kind of going over the business case, and then I'll get into more details of the activities that you can start to take to be able to improve your team communication. We thought that this is a great aspect as you're looking back over what you did last year and how you can do things better this year, and communication is always a place for an improvement. So there we go. So I wanted to look a little bit at business goals and what business success looks like for organizations. So a lot of organizations would come back and say that revenue growth, obviously bringing a lot more money into your organization, is a good way to measure success. Customer satisfaction and having the people who are buying your product happy with your product, that's always a good thing to have. Having efficient operations and allowing your teams to be able to multitask effectively and be able to streamline your processes, those are all really great measures of success, and as well as product and data quality. So there's the three-legged stool of money, time, and quality, and so having these different elements incorporated in your organization allows you to be successful. So according to that, and what are the key challenges in achieving those goals for business success? So one of the first things that jumps in that we're going to spend a lot of time talking about today is organizational silos. Organizational silos do have their benefits in an organization, but they definitely have their downsides, and we will talk about some different ways you can combat that. Process redundancies can definitely defeat your corporate success if you have business processes that are duplicated over time or, you know, I'm sorry, I got distracted for a second. Process redundancies within your organization can cause you to fail in your business. There's also communication gaps. So silos and communication gaps in your organization can definitely help to defeat the business success and slow down things. And then there's also operational inefficiencies. So the first thing is I'm going to talk a lot about silos. And there's natural silos that can be divided by team or department. So when you've got a, you know, a finance team trying to talk to your marketing team, they can definitely have different agendas, they have different goals. You know, marketing has their metrics they're trying to meet, finance has their metrics trying to meet. And so because they're pointed in very different directions, you can get a lot of natural silos in your organization. You can also be divided by objectives. So you can have your business objectives which are completely different than your technology objectives. So your business objectives may be, you know, grow the business by X amount, get this number of return on investment, get this number of sales in the door, get this many of leads where the technology objectives would be completely different in the sense of, you know, how many server beds am I using? And what do my databases look like? Is my product being built with quality? So obviously when you are pointed in those two different directions, you have very different conversations that are taking place and you can naturally be divided because you aren't having the same conversation. Silas can also be created by having different jargons. So obviously the business jargon is very, very different than the technical jargon. And here I use kind of a word cloud to kind of show some of these different words, how they're, you know, they're very, very different conversations that you're having even amongst team members. So if a technical person comes and walks in on a business conversation, there may be a lot of terms that they wouldn't understand and vice versa, especially when you're talking from the business side to the technical side, because business side is frequently in common language, even though there are the jargony words, versus technical kind of really has its language of its own. And when you have two different teams that are trying to talk to each other and they've got different words that they're using and different objectives that they're trying to meet, this can create a lot of different silos. So that being said, not all silos are necessarily bad. There are good silos for your business. And I'll start kind of going through how those can be valuable. So in the sense of silos can provide a structure that allows employees to do their work with fewer distractions. So if you have a very set objective, you are isolated away from your other coworkers, you can get your heads down and not be so distracted versus if there aren't the silos, an individual who maybe is in development goes and hangs out with the sales team and they're talking to the sales team. The sales team starts to give them new ideas and new conversation and they get distracted from the work that they were trying to do in the first place. So there can be good aspects to having silos so that people can hone in and focus and hunker down on their objectives. It can also facilitate expertise in specific areas of the business. So if you are focused on one particular aspect, let's say it's on data governance, then you can hone in and get a lot more expertise if you don't have to be a jack of all trades. You can focus in and know everything and anything and everything about that particular topic. You can focus and do all of your research and all of your gathering and become the subject matter experts. So silos can divide you off and create good expertise as well. My clicking is not as fast as I expected. It also speeds up communication by allowing people to speak the same language. So if you have, like I said previously, jargon can frequently interfere between two different departments that speak completely differently. But if you have a team that's got a jargon, they've got a lexicon, they've got defined terms within that group, then they can talk a lot more rapidly without having to explain those concepts over and over and over again to people who don't necessarily understand those concepts. So that could definitely be a good element of silos. Another good element is keeping accountability and responsibility within the silo. So when you have those silos broken down and it's very clear this is your job, this is your role, then if something goes wrong, you're the first person for people to go to to get the answer. It is your responsibility to make sure that that element happens or that item is corrected. So there's definitely good aspects in having a lot of accountability and responsibility so that you can go to one particular person and get whatever information you need from them. That can be definitely a good benefit of a silo. And the reason I'm kind of going over these good benefits is because a lot of times people talk about silos very negatively. And then the last element that I'm going to bring up today is it fosters a sense of pride and ownership. When you are siloed and you have one soul responsibility and you're focused on one soul thing and you do that thing very, very well, then you can have a lot of pride and a lot of ownership over that job well done. So these are all really good elements of silos and these are things to continue to foster even as you start to break down silos in your organization and open up communication, these elements still need to be maintained so that people can feel good about the jobs that they're doing but not overly so so much that decisions are made with one individual instead of involving the group who have multiple different objectives. So then we'll talk about the sour side of silos and how to use business processes to overcome them. And as I walk through this, I will be showing you some different business processes. They're very high level business processes. They are not complex on purpose. But business processes certainly can become very complex, very drawn out, lots of different information, lots of different directions but I didn't think that that was the purpose of this conversation. All of these business processes that are used in these slides have been created using the ER studio business architect product. So the first thing is that silos create inefficiencies and redundant processes and this was the part where my brain was jumping ahead to a couple of minutes ago. One of the things, in this case, let's say that you have a marketing team and you have a sales team and you start to diagram out that process and you say okay, so the marketing team is going to start their campaign, they're going to receive the new leads, they're going to qualify the lead, they produce a lead list. And when that lead list gets produced, they then send it on to the sales team and the sales team receives the lead. If they didn't know that the marketing team was also qualifying the lead, they would double qualify the lead and then they contact the lead and then they can identify the lead as the actual customer that they want to be able to pursue and move forward in the process. But if you sit marketing down and you sit sales down and you have them both go through all of their processes, you can start to identify these cases where oh my god, my marketing team and my sales team are both qualifying this lead and why are they both doing it and in which case do I really want them doing it? Do I want it to be qualified in advance in marketing so I have more qualified leads before they go on to sales? Or do I want to get this giant bucket and let sales define what makes a qualified lead? So by doing this kind of practice and going through your processes, you can clearly show the places where you've got some different redundancies and efficiencies in your process. Another case in when you're identifying those redundant processes is when you're merging processes and in this case I've talked about two different companies perhaps coming together and becoming a merged company. And so in company A they come and they say okay I've got my call that's come in, I've gathered my customer info, I've highlighted my specials and I take my order versus company B they gather the customer info, they take the order, they also send a survey. And so if you can blend those and combine them together and you can say you know I really like the fact that company A highlights their specials and company B sends the surveys and that is better defined that has all of those different elements in it the good elements of both companies. So not only can you reduce the inefficiencies but you can also find better best practices within organizations. Another sour side of silos is the gaps in communication between departments where collaboration is not happening but it should be. So in this case I've done a sales and a finance circumstance and in this scenario the sales a new product is released, they tell the customer about the product, they sell a proposal, send a proposal, they negotiate the deal. When they negotiate the deal then finance has to do something and here they may have updated those product prices and then review the incoming deal and then build a customer and if they've updated the prices then that obviously could negate the deal that the sales team is doing and so if the sales team didn't know that until the finance team went to review the deals then they would have to go back to the drawing board and figure out again okay I've got to renegotiate the deal and I've got to incorporate these new prices again. So having these conversations and understanding what elements need to happen when can really help to break down the collaboration gaps that are happening in your organization. The next element or next business process model that I'm showing, this is what's called a conversation model and in this case you have multiple different pools that are representative of departments to be able to handle these complex circumstances and understand who needs what handoff in the process when. And so you may have a sales person who's in there and they need to talk to a sales engineer to set up the product and the sales engineer then demos the product to the client, the sales person may have to go to sales management to approve the deal, the client may have to go to the shipping company eventually I'm sorry go down through the process, you go down to finance and finance management, the operations team, the suppliers, the shipping companies to finally get the item to the client. So in this case you can see some of those quick touch points and understand what are the two departments that are involved so that nothing gets lost in communication, the ball doesn't get dropped and communication flows freely between the different elements in order to see the deal complete itself. So in this case I'm going to talk about rogue processes that do not benefit the company. And in this case if you've gone through your process and you started talking to in this case we're going to deal with product and development, I try to change them up because I don't want to pick on one particular department or another one. But in this case the product goes through its release, you define the requirements, you deliver the requirements, it goes to development who then receives the requirements and they begin development. Now in this case if you have gone through and you're still talking to customers and you're revising your requirements through the release process and then you deliver those revised processes to development, then they've got to go back and redevelop the product again before they can fully complete it and release the release back to the product team. In this case the product team has completely gone rogue and I did pick on the product team on purpose since I'm on the product team and of course I would never go rogue but in this case you're adding extra complication and stuff to the process and if you took that piece out where you're revising the requirements and talking to the customer and put that before you actually delivered the requirements to the development team then it would make the process flow a lot better, it would be a lot less complicated, there'd be a lot less back and forth that goes on between development and product and the product would be released faster. So in this case I'm going to talk about the duplication of assets and resources and so here I'm going to use some product models to kind of go through that. In this case we've got the various different applications that are being used, the various different people that are using them and we have the CRM solution which is by both sales and marketing and understanding okay so they're using the CRM and I don't necessarily need two different CRM tools. I may have the, you know, tutorial video editing tool over here in the product team and I may have another one in marketing and if I've got two of those that are going at the same time then I certainly don't need two of those. I may have the call tracking tool that's going on between development and product and have a whole different call tracking tool that's handled by sales and you can look at your assets and look at your resources and start to identify where that information may be duplicated and you may be able to streamline it and bring it together. Now certainly there may be cases where it makes sense to have a different kind of bug tracking software for product and development than the call tracking software that you have for sales but you at least can have the conversation and identify when those resources might be duplicated and ways that you can, you know, buy less versions of software. Another case is to identify who's responsible for that information. When you go and in this case I've got several different tables that I've laid out and I've got different types of data that those tables relate to and different data stewards who apply to owning that information. Then you know very quickly which resources are assigned to that information when you need to know more information about financial data. Let's say that you heard about a new financial regulation that's come to be. You know you can go to Quacky McDuck and start talking about, okay, how is this going to impact your tables? How is this going to impact information? What's that going to change? Is it going to change anything? If you can really clearly identify who's responsible for which elements of information then you can not have duplicated resources and have very fine-tuned conversations with those individuals. Another sour side of silos is poor data quality and data inconsistency and I figured that would be a big hit on this group. I'm sure none of you have ever encountered that before but in this case you may want to go and define that data behavior. So when you're looking at the difference between do I need to create a new customer or do I need to update an existing customer you would go through this flow that says, okay, is the email address unique? If it is it's a new customer. Is the last name unique? If it is it's a new customer. Is the first name unique? If it is then it's a new customer. And is that address unique? And if it is then it's a new customer. And if the email address is not unique from the last name, the first name and the address when you tie all four of those columns together they are the same customer and so we're going to update the existing customer. And being able to have this conversation with the business side as well as the technical side is essential in identifying how behavior is going to act in the system before somebody starts creating the system, before somebody starts testing the system, before users start using the system, if you can do this in far enough in advance and have this conversation then it completely streamlines your development process. And the fact that this is in a pictorial case and we don't have a lot of jargon in this case. We don't have a lot of specific elements that deal particularly to the business side or to the data side. You can really quickly hone in on this and everybody can see the same picture and see the same flow and understand what is happening with that data. And obviously this is a very, very simplified case of data information but I'm sure that you can take it in your brain and understand how this can become much more complex. In this case, I've got an example of determining data duplication and we've got an example of a retail customer versus a web customer and the information that you may be collecting in one sense may be different than the information you're collecting in the other sense and because retail systems are one system and web systems are generally a different system trying to identify what information you are collecting and it's the same across those systems is really imperative. So in the retail case, you look and you say, okay, my customer is going to come in, they're going to purchase my item. My clerk is going to enter those items. They're going to swipe their credit card or take their cash and the system is going to update the inventory versus the web customer, they will go in, they put elements in that information, you get, again, the way that they're going to pay for it, you get shipping details because they're not buying it at the store, you've got to shift that information to you and again, you update the inventory. But you can see in both of these processes, there is order information that's gathered that's going to probably be pretty similar. Financial information which will be very similar, inventory information which will be very similar, but obviously the web customer has a customer account that's different and they have shopping information that's different. So being able to look at this kind of a view and be able to understand where information is duplicated, where systems are duplicated, where that information can be consolidated because in this case, it can be exactly the same customer who's ordering something by walking into your store and as well as ordering something online and being able to track that and have the most relevant and data information at the time is really essential and having a diagram like this helps your business team to be able to look at the technical details and understand how the process is going to be affected so that the data team can go and build the right systems and build the right tables and map the right elements in order to make the process work. So in this next section, I'm going to talk about tips to break down the silos for business success. Oh, wait. I'm sorry. I've got one more. Additional benefits of good processes. So employees can identify issues at the beginning when it's easier to implement changes. We all know that if you can do things in the analysis and design process before it's even built, it takes far less time than if you try and change things and then try and change things again because that continues to consume valuable dev resources. In this case, I've shown the very beginning preliminary conversation of you starting to draw out a good process. So if the customer calls in, isn't an existing customer, if it is, then I'm going to collect the customer details. If not, I'll create the new customer record. I'll take the customer order. I'll gather their financials and I'll place the order. I do maybe know that the financials at least are going to be in the financial system. But where I've got all of these different annotations here, they're points of having the conversation of saying, okay, guys, we're at this point in the process. Now, what other information do we need to gather? And what information do we have to gather here? And what details do we need? And being able to start to flesh those out so that they go, oh, you know what? I haven't given that information to you yet. So that you're not gathering it when you're building that element to create a new customer record, you're talking about it up front so that that information can be consolidated and not duplicated and not captured several different ways within the system and have to be mapped together and integrated together at the end. Another additional benefit of having good processes are that new employees can be onboarded more rapidly. So it isn't always the case that it's helpful to your development process. It can also help HR and streamlining what's happening so that everybody is brought on the same way. Everybody understands the same training. In this case, you know, I did kind of another salesy one where, you know, you want to create the email account, you give them access to documentation, give them access to sales force, you give them access to contracts, you set up your orientation and training and then have these elements that drop down that say, okay, so these are the different kinds of documents that the person is going to need. This is the different systems that they're going to need. And rather than doing it differently every single time and missing having a step set up or, you know, and it's very frustrating, especially when new people come on because they don't know what the processes are. They don't know what they're supposed to know or what they're supposed to have. And it can be weeks down the road before they go, oh, I was never given access to that information. This way you can streamline the process so that every single time it is done the same way every single time and that, again, your business team or your team that's not business, your finance team, your marketing team can look at this process and say, yep, that's the way it should be. These are the elements that need to be done. This is the access that needs to be granted so that you can get your new employees on faster. Another benefit of having good processes is that decisions can be made in real time across cross functional teams. So in this case I've built a business process that is going between development and QA. And I know that I'm going to send a dev build over to QA and they're going to receive it. They're going to identify some defects. Devs are going to go back. They're going to resolve the defects. The circle is going to complete itself over and over and then finally it's going to be released. But being able to have this conversation with development QA say, okay, so how do we determine which defects we want to resolve? How do we deem that testing is complete? And if you start to draw out this process so that everyone knows they're different handoff points and you have a representative from each group in the room, you can start to answer these questions and answer them in a joint way so that decisions can be made really, really quickly. Because the development team will want to know which defects am I going to resolve and the QA team needs to know which ones am I even going to report to you in the first place. And so if you can come together and start to have that conversation, then this can help your processes flow a lot more smoothly without much error. So then now the tips to break down those silos. So one element is to focus your business processes on your customer, your products, or your services, not just the individual departments. Because when you break it down into the individual departments, again, you get a very siloed view. You know this is the email marketing person's job to do these things. And this is the process that I need to follow. But how does that affect your sales person at the end of the day? You know when they get those leads, is that effective information for them? And if you can instead look at the customer process that says I'm coming in as a new customer and then I get contacted by a sales person and then the sales person does these things and then they go and they talk to this group and so on and so forth, then it becomes the whole journey of the process instead of just the isolated individual siloed process. The business case that I'm giving you here is one for support. So a VIP customer calls in. You've got an account manager that's managing it. They know that the customer has a problem. They get the description. They figure out can I handle it myself? And if I can, I'll explain the solution. And if I can't, then I'll send the mail to the support system and then it falls into the support process. And the support story. So it goes to the first level support and they decide, you know, if the issue has been received, I'm going to open a ticket. I'm going to edit the first level ticket. What's the result? Can I resolve it? If so, I'm going to send it back to the account manager and I'm going to close out the ticket. If not, then I will take it down to the second level of support where they're going to go and they're going to insert the issue into the product backlog or if they can resolve it, they'll send it to the account manager. And so having this conversation that is from the view of the customer issue has come in, what's the process, then you don't just have the account manager's role. You don't just have the support system and trouble ticket system role and you could certainly drop this down and be able to go into the development processes and be able to build out a very robust solution where the entire team can look at it and it breaks down those silos that happen just between this is my job, this is my role, this is what I do. So this is one example of a business process you could design. Another tip for breaking down silos is to spend more time discussing the places where the processes connect because we all know our own jobs or we should all know our own jobs and responsibilities but you should spend more time talking about where those processes are connecting and where those handoffs are taking place because that's where you're going to get the most of your inefficiencies, that's when you're going to get the most communication gap, that's where the silos are going to start to break down and really diminish communication within your organization. So here's a business process that the presales goes in, they figure out the requirements, engineering develops the product, they sell it to the customer, the post sales verifies the requirements, a consulting group says okay, I've got consulting required, I've got bugs that I diagnosed and I send it off to my engineering team to develop the patch. So this is a pool version that shows these different silos all have to work together to be able to get the job done and being able to look at these arrows that point from one pool to the next pool you can have a lot more conversation about okay, so what really happens between developing the product and selling to the customer? What are the handoffs? What information does engineering need to provide the sales before the product goes out so that they can be better equipped to handle it when that handoff takes place? What information needs to take place so that sales can be prepared and ready to go and really talk a lot and break down that line and break down that handoff point so that it's very clear what's going to happen as different elements flow through the processes within your organization. An additional tip to break down silos is to unify your employees by showing how the processes that they're responsible for interact with the company as a whole. Because if your employees can understand my individual work that I'm doing goes to achieve this goal for the organization. It does give them more pride. It lets them know more that they're fitting into the organization, that they have a purpose that, you know, and they understand the handoff points and they understand what's trying to happen amongst the different teams. In my own career, because I've worked in a variety of different roles, I have understood, you know, what their customer support is seeing on the front line. What is development trying to do to get that product out the door? What is the product manager trying to do to gather the requirements from the sales organization and from all of the customers and the market feedback? And I've worked in those elements but that's not a normal progression for a lot of people in a lot of organizations. A lot of people start with one role in their career and that's the career that they end up, you know, in for their life. And so understanding how they fit in with the other cogs on the wheel and the other things that they're trying to accomplish can really help to break down silos. In this case, I've done a business process diagram that has handoffs between customers, manufacturers, suppliers, bidders and, you know, understanding how the process is going to flow when you've got, you know, a semi-complex system. Again, these aren't very complicated diagrams. But so the order comes in, customers place an order with the manufacturer. The first question you have to ask is can it be fulfilled and if it can, you confirm that order with the customer, you deliver the order and the order is delivered. If you can't deliver it, then you might decide, okay, I just need to get more parts for it. So I'm going to procure the parts. I'm going to go to a part auction. Once I get on my parts, then I can deliver the order and things can move forward. Or if you don't have the parts and you can't fulfill the order, then you can potentially end up rejecting the order. And so understanding, okay, so the manufacturer's got these different pivot points. The supplier's got different pivot points. The bidder's got different pivot points. And really understanding how those things flow together and become a team that ultimately satisfies your customer. Another element to help to break down silos is to collaborate with all your employees so they have input on the processes that affect their role and job. I frequently think of the TV show undercover boss where the CEO of a corporation who is so many levels away from the people that are working on the bottom floor go and for a few days they work with those employees and see what they're dealing with on an everyday basis. And some policies and procedures that you put in place may have a drastic impact further down the road. You think it's cost-cutting because you've said I'm going to cut out the training of my salespeople on the sales floor because they don't really need it. They should know this product but then when you get there you realize maybe they don't really know that. They don't know about the new features that are coming out or the new scents that are available or the new flavors that are available or elements like that. So making those business process decisions without talking to the people who are affected by those processes can definitely cause for a lot of communication breakdown. It can cause a lot of gaps in an organization. And so collaborating with all of your employees or at least representatives of all of your different employees as you build out your business processes really can have a profound impact on communication and breaking down the silos in your organization. The last element that I'm going to cover is to update your processes regularly to reflect the changing needs and the goals of the organization. If you are going through and making sure that your processes are up to date and everybody knows about them, they're all documented, then as your goals continue to change in the organization it makes it very easy for everybody to be able to step into the process and reduce some of that change and some of the conflict that happens within when processes change. So that's kind of a high-level overview of some of the different ways that you can create business processes to be able to get over these hurdles that happen within business communications and within silos. And I'm now went a little bit ahead of time so I'm happy to answer questions. Kim, thank you so much for another great presentation. We've got questions coming in already. And if you have questions, feel free to submit them in the bottom right-hand corner of your screen in the Q&A section. And just a reminder, I will send a follow-up email to all registrants by end of day Thursday for this webinar with links to the slides and the recording and anything else requested throughout. So Kim, just diving into it, as an organization or company considers its options on infrastructure and policies, what are common missteps with regard to soft skills assessment and alignment to duties? I think that whatever I've also had a stint for a little while in recruiting and I think that the biggest problem is understanding what you have fostered in your culture and then being able to attract talent that fits that culture. And so going through and really understanding your company culture along with the processes and skills that individuals need in order to fulfill those roles can really help you in defining your organizational structure and who should be in what kind of roles. So for example, I had a sales team that I was working with and they wanted people who were not very social in the office because the office environment didn't have a very strong culture but they wanted them out in front of the summer all bubbly and everything else and so they needed to look at those processes and say, okay, well back at the office we're not really fostering a sense of collaboration and communication but we want these people to go out and communicate in the field and so they started to change a lot of what was happening within their office to foster and facilitate these very chatty people so that they wanted to stay in the organization and they didn't have to split their personalities between customer facing and internally within the office and if you can really understand what's important to your business you can start to define what those characteristics are in order for someone to be successful in those roles. And we get this next question a lot, Kim and of course it was inevitable that it would come up all too often there appears to be a disconnect between check and business units, sales and best office. Thoughts on best practices with regards to training and approach to training? Yeah, so I'll put up real quickly, I'll put up the jargon one because that's one of my favorite little word cloud there. So the first, the business process diagrams that we have here are extremely helpful because they're pictures and they say a picture draws a thousand words but it really when you're using these kind of systematic pictures to describe things you can cut out a lot of the different jargon that takes place and if you, if everybody kind of understands this is the process and this is the flow, I'll go to the merging process one for example, you know everybody is on board and they say okay this is the way that the process is going to flow and it helps to streamline the training, it helps to everyone to understand kind of what's going on and what's happening back and forth between the different teams in the organization. That helped or was that muddied? I was kind of talking off the top of my head. I love it. We'll give the questioner a moment to weigh in but I'm just kind of moving on, you know, Kim, as you show this too, you know this is great to show the types of diagrams that may be civil for certain situations. Do you have an index for document that shows which diagram may be suitable for certain situations? I don't in this particular slide. In the business architect product we have sample models that come delivered with the product. A lot of it is focused on BPMN and the types of process models that you can create using them and so we use a lot of, you know, variety of different industry examples whether it be, you know, a doctor's office or whether it be, you know, figuring out the process to accept a Nobel peace prize. And so we try to do kind of more general cases so that someone can say, oh, you know what, that process would fit into what I'm trying to communicate right now and what I'm trying to get across to my executives or what I'm trying to get across to the team that I'm building the product for and, you know, to kind of start to map it out. I mean, you've got, this is a collaboration diagram that's up. You certainly in some cases could use a very simple business process model that just has a flow with some different objects hanging off of it. You could use a collaboration diagram which is used kind of when you're really talking at a high level back and forth between, you know, showing that handoff between the different parts of an organization. So this one's the collaboration diagram. You've also got the choreography diagram which was one of the later ones that I showed you guys that's really for when there's two people that are involved in the decisions that it takes to complete a process and what are those different kind of high level handoff points between them. So there's a variety of different ones and certainly Google is rampant with business process diagrams that help you to, you know, think through and say, oh, this is what I want. But I tell people that you should start out with a smaller project, you know, don't try and diagram everything all at once. But just sit down and think what are even my processes to begin with? And then I go, okay, so these are my processes. Now what points do I hand off to other people? And then I start to build out those processes and then I can go and talk to them and say, okay, here's my part of the process, here's your part of the process, here's the parts where I think the process are breaking down and we need to have some more conversation regarding that part of the process. I just use the word process a whole lot. It's a great word. So for a subject matter expert with limited resources, can an appropriate ERP system address the problem without having to introduce multiple systems? I think ERP solutions really try to do that. They try to say this is a common scenario, this is a common path, and generally you have some sort of consultant who comes in and figures out how to wedge that square peg into the round hole and develop that ERP solution. For industries where things are very repeatable, that works, especially in industries that are really overly regulated, that can work as well. But certainly for the industries that are innovative, that are cutting edge, that are very creative, nothing is cookie cutter. And so, yeah, you could use an ERP solution to drive your CRM solution into your financial solution and let that all flow. But you still have the people at the end of the day and you still have to let them know how process should flow and how communication should happen within the organization. So, yes, partially, yes, ERP solutions can help in some circumstances, but in other environments it may be more of a burden to have to follow that kind of a process when you really don't fit in the process. Sure. So what is your thought on if the org itself has many verticals due to the size, which also causes, causing process deficiencies? Yeah, I mean that's one of the main places where processes can really help you out. We have some customers that are giants and they have gone through and created these business process diagrams for everything, everything, everything. And mostly those are the ones that are really over-regulated where you have to prove this is my process for doing this and this is the way that it was followed. And they then share those process diagrams to their organization and there's a process for everything that needs to be done in that organization. In some organizations that can certainly be overkill and to create it could be very difficult, but you certainly could do that within a project team, within a certain, and it helps if you have an executive sponsor who believes in diagramming your processes and understanding and doing this kind of collaboration. But even if you did it for one particular project and then that project shows success and it's like, oh, all of a sudden everybody's communicating effectively. We don't have as meetings as we used to have. We don't have to have as many approvals because we believe in the process and we know that the right people and the right checks and balances are in place and you can then start to show that that process worked and move it throughout the organization and other aspects to think that you would just do that with a giant organization and have everything diagrammed. That would take a giant consulting force to come and document all of your requirements and processes. But certainly you can start at the littlest point and then start to let it kind of grow organically through the organization. So kind of going back to the technical versus business development and streamlining of tech, dictionary and business glossary. Who should be involved in determining definitions and using a usage in giving respective areas? Yeah, I've been involved in long, painful conversations about lexicons and business glossaries. And trying to get everybody on board to even create the same product names. It can be quite the headache. And it can happen one of two ways. It can be I'm in my part of the organization and I call these elements these things and I'm going to build a business glossary that says this is what an order means to me and this is what a customer means to me and this is what inventory means to me. And then another organization can say okay I've now gone and looked at that but what you call customer I call contact. So I'm going to map customer to contact so that we know that within this team when you say contact it means this team their customer. Which certainly could work or you get the two teams together and you say okay guys I see that in this case we're talking about inventory in this case we're talking about orders and they to me mean the same thing. Let's sit and discuss this and then figure out which is the better term. What is the term we want to use at the organization as a whole. And there may be somebody who is responsible for the glossary in the lexicon or it may be a you know just coming together of the heads of that group or you know it could even be the you know the people who are on the ground floor doing it as long as there is somebody who you say you have the authority to make the decision on what this is called. So you know can you touch on silos emerging due to geographic dispersion on a global business environment? Yeah so certainly I mean I think that globally probably isn't that much different than even if you have people in the you know in the same office I think you have the same kinds of communication issues. The way that globally becomes different is cultural differences and you know availability of resources in some environments you know like in France people can only work 30 hour weeks they do that because they don't they want to decrease unemployment and if you're working with a company who's got employees in France they wouldn't be as available and so you have to figure out what is the process that I'm going to do with those individuals versus you know maybe I do I split the individual tasks between two people that are working 30 hours a week instead of over here in the United States where people work 60 or 80 hours a week sometimes and so there are cultural differences that definitely cause divides and global organizations but beyond that it's the same as even if you were sitting in the same office where you've got giant silos and people aren't talking to each other and sometimes because of the good things that come with silos an organizational culture will embrace the silo and you have to figure out how to get in there and break it down so that you could have this conversation and I think that when you've got these kinds of overlapping where you say I'm going to look at the customer's journey and these are the different parts of the organization they need to have this handoff you can kind of chisel away at the secret processes of one silo versus another silo and start to really map it out so that you can see this. So I guess again like convoluted off the top of my head answer is there certainly are things to consider in regards to global companies but I don't think that they're that much different than any other company that may be highly siloed for reasons other than geographically. Kim these answers are great and you know while we're on the topic of silo stills how can silos merge following merger or acquisition? Yeah so I think that I did have the very obviously again I didn't want to overwhelm you guys with really complex diagrams but in this case if you can go through and you plot out the processes that one organization has versus the other organization and you figure out you know what's the win condition you know and being able to understand wow that's a really great process that that company was doing I want to fold that into what my company is doing and finding those best practices and sometimes it's not even like the whole company maybe it's just an individual in the company that's got a really great process for doing something and when you start to diagram those out and you start to talk about them and you say okay you know how do you gather customer information and when you look at those details it's like wow that's really cool you know you're going out to LinkedIn to find more information about them or you're going to you know you're searching Google and you're finding out more information about them rather than I just got this lead that came in and I'm just all I have is their contact information and depending on the organization and the velocity that you're trying to travel in and how high touch you want one organization the other could win out in that company culture so it's like okay either I do want to know everything about everything about everything about my customer or I just need to know is my customer going to buy this or not and so looking at the different ways even that a company gathers customer information can end up in this really great merged process of the best choices for the organization. I love it and we've got time here I think for at least one more question. So can thoughts on best practices on buy-in and shared ownership of all units and divisions? I think that the best way to get buy-in for all units and division is to have an executive champion finding an executive at the top who sees that there is a problem with the silos and sees that there's a problem with the communication and wants to break down those walls of secrecy between the different parts of it. If you have that executive who can be the champion then they can help to run it across to their executive peers as well as run it down their chain of command in order to get these things approved and brought on. It's really frustrating as an individual where it's like everybody's pointing fingers and you're like, oh, if only the marketing team did this then I could do my job better. Oh, if only the sales team did this I could do my job better or whatever. And to find that executive at the top who says, okay, you guys all can be doing your job better and let's sit down and figure out how we can do this. That executive champion it really can be very key in driving these kinds of processes. All right. I'm afraid that is bringing us to just right at the top of the hour here. Kim, thank you so much. There's a lot of comments in here about what a great presentation this has been and what a great plot. Make sure you see those and send those to you. So thank you so much for joining us today and speaking. And just a reminder I will send a follow-up email to all registrants by end of Thursday with links to the slides in the recording of this session. And I hope you can join us during the webinar on February 27th. Battle the dark side of data governance. That will be fun. All right. Thanks, everybody, for being engaged in everything we do. And Kim, thank you so much and thanks to IDIRA for sponsoring today. Thank you. And have a good one, everyone.