As VP of software, Ken Crutchfield oversees all aspects of the BNA software businesses of Bloomberg BNA, a wholly owned subsidiary of Bloomberg LP, including business strategy, new product introduction, and accelerating business growth. Bloomberg BNA’s flagship software product is BNA Fixed Assets, a leading product for managing enterprise assets for tax and accounting purposes. Bloomerg BNA is also a leading source of legal, tax, regulatory and business information for professionals that focuses on delivering expert analysis, news, practice tools, and guidance to clients. With over 25 years of experience in converging information and technology, Ken has managed five businesses and overseen the launch of numerous software and content titles. In the following interview, Ken shares insights on how leaders should think about data and how he and his team use integration to deliver critical information to customers.
Vice President • Software Bloomberg BNA
Q: Do you see a difference in the way you and your clients view data integration both now and in the future?
A: As a commercial software provider, we’ve really expanded our efforts to integrate data between customer systems and our tax software products. It’s increasingly important and, while our customers are willing to perform some tasks manually, the sheer volume of data requires them to automate as much as possible. This makes it imperative we overcome any challenges that come with integration. In addition to being able to fully automate the process and get it right, we need to collect information from different sources to deliver to customers more comprehensive and flexible solutions. Tax law and regulatory changes in our business can drive significant changes in customer data. This means we often have to gather information from disparate sources outside of ERP systems, including data that is actually housed in spreadsheets. Overall, we are working to be all-encompassing in our integration efforts and attempt to take data from any sort of solution and in any format.
Q: Are there times the scope has changed or you’ve had to look at the problem differently to get to a solution?
A: From my experience, scope creep in most projects is inevitable, even if you have a good set of requirements and discovery processes. Almost always, you will end up with some unexpected changes, but the more a team understands the problem it is trying to solve, the more it will understand the full scope of the requirements. The key is to continue to reference back to the original project goals to manage scope. If an issue is identified or if there is new information that wasn’t fully understood, then the scope should change. But generally, if you have clearly understood objectives for what you’re doing, those objectives can be used as a driver for managing scope.
Q: What should business people know and think about integration to be successful?
A: Well, the most fundamental point to recognize is that business is dynamic. The data and systems are always changing and the business drivers are changing. For example, it’s not uncommon for companies to acquire, divest and reorganize businesses, which means the scope of the business is evolving. Therefore, project teams need to be ready to make iterations and tweaks to integration projects to ensure they are aligned with the changing needs of the business. In my world, tax and accounting regulations change every year. Worst of all, some changes mandated by Congress or the IRS are retroactive, so when dealing with tax and accounting, this means companies must not only access their own data in real time, they need systems that can handle retroactive changes that impact prior years. Our solutions handle complex scenarios like retroactive changes and work with an open platform philosophy. In other words, today’s complicated technology infrastructures require that software play nice together. Closed solutions do not work for the modern corporation and can stop an integration project dead in its tracks or require time-consuming manual manipulation of data.
Q: What are the key questions people should ask before jumping into an integration project?
A: Overall, you need to think about integration holistically. There are four key questions everyone should be able to answer:
If the teams and leaders can’t really address these, you may end up on a proverbial death march building something that was flawed at a foundational level and could hurt the business and your credibility in the process.
Q: Were there any new processes that your team had to change as a project worked acosss different sources and systems?
A: In general, our engagements relate to implementing our software for a large enterprise. Our customer implementations are pretty smooth, but there are occasions when we have to make adjustments. For example, we recently had a customer that tested the limits of some of our web services and APIs based on the amount of data they were working with. We had to look at some changes in our core BNA Fixed Asset application to address those performance issues and ensure the solution worked well for our customer. With integration, there is always new territory to conquer and new problems to solve. When issues surface, focusing on the customer and the goals they want to accomplish ensures that as business partners, we and our customers will be successful.
Q: Were there any pleasant surprises data integration brought to you or your customers?
A: We have seen a number of customers who had to take ERP systems that were working fine and make some significant modifications because of tax regulation changes. For example, the tax law allows a company to reclassify certain assets to shorten the depreciation time for tax purposes, which can reduce current income tax obligations, but also require significant changes to the structure of fixed asset data within an ERP system. Also, there are rules and regulations that the IRS puts out on repairs. So if you repair something you have to adjust the tax basis of the asset. ERP systems are not designed to handle the various factors required to accurately calculate fixed asset repairs. Over time, customers can find themselves managing data and workarounds using manual processes, which are error prone and can take weeks to complete. However, we have also seen customers who’ve experienced these kinds of issues and, with proper planning and integration, can automate the work to complete the same tasks in a day or less. This can dramatically shift their work from drudgery to focusing on analytics and planning that offer personally rewarding insights that also impact their business.
Q: What are the most important insights your colleagues should know about data?
A: It is easy to get caught up in the implementation of a project and lose sight of business goals. We try to focus on the business goals and understand how the changes impact and are viewed by the C-suite. Keeping your eye on business benefits is one of the most important things, but often, it’s easy for an IT department to look at projects in terms of the cost benefits and lose the overall business focus. Eliminating a manual process or improving productivity are easy to see, but there are other benefits that are more important from both a financial or control perspective to the leaders of a company. Understanding what the C-suite deems important and having their support is huge in terms of how one completes an integration project—or any IT project, for that matter. It really comes down to how to navigate the political web between the IT department, system users, and C-suite to gain strong customer advocates across the board. We spend a lot of time identifying the higher-level value points of a solution to move beyond viewing the project as simply a cost-saving exercise or eliminating a little bit of manual effort or productivity. We want our clients to be able to tie projects to key objectives like supporting growth strategies like mergers and acquisitions, improving Sarbanes-Oxley controls, closing financials faster, or reducing tax liabilities. These are the priorities that are more important to the C-suite. Explaining how your project supports their goals goes a long ways in terms of giving you the leeway and the resources to be able to implement your projects successfully.
Q: What are the biggest mistakes business people make when they start or get very deep into an integration project?
A: In my experience, most projects fail when the issues that were known up front get brushed under the carpet. In many cases, assumptions or risks the team either saw or should have seen were not handled. This could be anything from assuming that data is “clean” or that data coming from another department doesn’t require normalization or pre-processing. We recommend building in a “proof of concept” phase as a smaller component of an engagement. Doing some prototyping up front on a small volume of data helps to ensure you can get the work done to solve the problem at hand, while finding any issues you missed. The earlier you can identify any issues and wrestle them to the ground, the more effective you are going to be in delivering a successful project.
Q: How can IT better prevent integration issues upfront?
A: Planning for uncertainty is critical. If you have a large project, for example, you must account for staff turnover and vacation time or you risk the schedule slipping. Consider a 100-person team with a seven percent attrition rate. That would equate to seven people rolling off the project during the year. Without a plan to replace them or account for the resulting schedule slippage, your project would likely fall behind.
Additionally, larger projects are likely to have a certain number of “surprises” or unexpected events. I have seen teams put together an integration schedule that includes parts of a project that are known, but often don’t budget time, staff, or money for the unpredictable. By incorporating tasks to validate assumptions and address any unknowns, project leaders can minimize unexpected project slippage and costs that could undermine management confidence and even impact the business.
Q: How have you seen attitudes change after an integration project?
A: Depending on a project’s outcome, attitudes can be either somber or upbeat. Luckily, because our data integration projects almost always save our customers incredible amounts of time, attitudes are typically positive. Our core tax department customers work incredibly long hours, which IT does not always understand. Those customers are constantly working towards regulatory deadlines and are often the last to know of something that impacts their work. This forces them to fight fires and respond to issues they didn’t create. Since most corporations file their corporate tax return on or about September 15th, the entire summer is filled with long weekends and the idea of taking the Fourth of July or Labor Day off in the tax department is actually unusual. We’re able to implement solutions that take much of their manual work, such as data entry, and automate the work to shorten time-critical processes. Integration projects should solve business problems, increase productivity, and help with work-life balance. Individual project successes can be short-lived for members of the tax department. They can and need to celebrate their victories, but there is always another fire smoldering that will need to be put out.
Q: Name some of the challenges, behaviors or technologies that were tough to overcome.
A: Change management can be tough. The technology part is easy compared to process and culture change. Managing the Gannt chart and deploying functionality is one thing, but the real work—and the part that gets less attention—is ensuring that everybody is trained, knows the process changes, and is comfortable with the solution. If you don’t get the teams using the new solution correctly your project can fail. It’s natural human behavior to resist change. You have to work to ensure everyone is properly trained and knows the upstream and downstream implications. For example, we had a customer merge with another company, which resulted in a tax department and accounting department comprised of people from two different companies. They didn’t understand fully how the implemented solution would work for them. The change management caused problems because end users didn’t fully understand how to use the system as it was designed. Each department entered data their own way, causing data to get out of sync. We straightened everything out, of course, but if the problem persisted the project could have failed. Addressing change management and training as part of a project is imperative.
Q: Can you give us an idea of the costs associated with doing integrations well and doing them poorly?
A: I think it’s about identifying the real costs and benefits of a project. If the project goal is to simply reduce or eliminate some manual work or to become more efficient, then that may define the project budget and benefits. But often, the real costs and benefits are not as directly apparent. A project that appears to be just a productivity issue, may have much greater impact up the chain. For example, we’ve seen manual processes where tax departments are busy working on data entry, but are unable to take advantage of tax credits. We’ve seen manual processes that are inconsistent and create audit control issues that, if ignored, could ultimately impact the company’s bottom line and even their stock price. Missing the underlying benefits can give the impression that a project was done poorly when it was actually done well.