Business Driven Information Systems Baltzan

Why Most People Get Business Driven Information Systems Wrong

They start with the technology instead of the business process. I have watched this happen repeatedly over the last twelve years. You buy an enterprise resource planning system, or a customer relationship management platform, or whatever buzzword is trending this quarter, and then you try to force your operations to fit inside it. It rarely works out well. The concept behind Business Driven Information Systems Baltzan flips that around. You identify the actual business need first, then you select the tools that serve that need. The Baltzan textbook and framework that circulates through university programs covers this fairly well, but reading about it and actually applying it are two different things.

Getting Business Driven Information Systems Baltzan to Work in Practice

Here is how I approach this when a company comes to me with a broken process. They usually have a patchwork of spreadsheets, a legacy database nobody understands, and three different software licenses they cannot get to talk to each other. The first thing I do is not look at any of that technology. I sit down with the people who actually do the work. The clerks, the shift supervisors, the sales reps who are entering data at 11 PM because the system crashes every time someone tries to run a monthly report. I map out what they are trying to accomplish. What is the actual business outcome they need? Revenue tracking, inventory management, compliance reporting, customer retention, something concrete. Once that is clear, I look at their existing systems and figure out what is actually broken and what is just poorly used. Most of the time the problem is not the software. It is the process design. When I actually implement a business-driven information system, I usually start with a pilot in one department. Not the whole company. Pick a team that has a clear, measurable process. Track everything. Time spent on data entry, error rates, turnaround time from task start to task complete. Establish a baseline before you change anything. Otherwise you will never know if the new system actually improved things or just moved the bottleneck somewhere else.

One specific edge case I ran into last year involved a mid-size manufacturing company that wanted to implement a new supply chain management system. Their stated goal was reducing inventory costs by twenty percent. That sounded reasonable until I spent a week shadowing the warehouse team. They were manually counting stock every Friday afternoon because the existing system had a two-day lag on inventory updates. When we finally got the new system deployed, the first month showed inventory costs dropping by twelve percent. Everyone was happy. Then in the third month, costs went back up. The problem was not the software. The problem was that the warehouse staff had started using the new system exactly the same way they used the old one, which meant the data was still entering two days late. The workaround was implementing real-time scanning at the loading dock and tying inventory updates directly to shipping receipts instead of relying on periodic manual counts. That cut the update lag from forty-eight hours to about four minutes. This is the kind of thing that does not make it into textbooks. Business Driven Information Systems Baltzan describes the theory cleanly, but theory does not account for the fact that your warehouse team will continue doing things the way they always have, even after you install a million-dollar system. The technology is the easy part. Getting people to change how they work is the hard part.

Common Pitfalls When Implementing These Systems

There is a misconception that if you buy the right software, the business will automatically become more efficient. That is not how it works. I have seen companies spend six figures on a customer relationship management system and then realize the data their sales team was entering was garbage. Incomplete records, duplicate entries, fields left blank because the system asked too many questions during data entry. The system was sophisticated. The input was not. Another frequent mistake is building a system that is too flexible. You want it to handle every possible scenario, so you add custom fields for every department, workflows for every edge case, and permissions for every role. Six months later you have a system that nobody understands anymore, not even the people who designed it. The original architect left the company. The person who took over does not remember why certain fields exist or what workflow they trigger. You are now maintaining a system that is impossible to modify without breaking something else. Enterprise resource planning implementations have a failure rate that hovers around sixty percent according to industry studies. Most failures are not technical. They are organizational. People resist the new process. Management loses interest after the initial rollout. The project drags on for eighteen months instead of six, and by the time it finally launches, the business has moved on to something else. The system is technically sound but contextually irrelevant.

Here is a counter-intuitive insight that might save you some pain. Sometimes the best business-driven information system is not a system at all. It is a simplified process with a spreadsheet and a shared drive. If your company has fewer than fifty employees and you are trying to manage everything in a complex enterprise platform, you are probably over-engineering the solution. Start small. Document the process clearly. Use basic tools until the process becomes too complex for those tools. Then upgrade. Most companies skip that step and try to run before they can walk. Another thing nobody mentions is the hidden cost of data migration. You think you are just importing customer records or inventory levels. What you are actually doing is cleaning ten years of accumulated mess. Duplicate records, missing fields, formats that changed across different systems over the years. A client of mine spent three weeks on data cleaning before they could even attempt to migrate their customer database. The migration itself took two days. The cleanup took twenty-one. If you underestimate that phase, your entire timeline goes out the window.

When Business Driven Information Systems Do Not Apply

There are situations where a full business-driven information system is the wrong choice. A startup with ten employees does not need an enterprise resource planning platform. They need a shared calendar, a simple accounting tool, and a way to communicate. Adding complexity before you have the volume to justify it is a common mistake. The system becomes a burden instead of an asset. Regulatory environments can also make certain systems impractical. Healthcare data, financial records, anything with strict compliance requirements. You might find that the most affordable or feature-rich system does not meet your regulatory needs. In those cases, you either choose a compliant alternative or build a workaround that adds cost and complexity. Either way, you need to factor compliance into your initial planning, not discover it three months after deployment. Sometimes the business problem is not technical at all. It is cultural. A company with poor communication between departments will not fix that problem by installing a collaboration platform. The software will just make the existing dysfunction more visible. You need to address the underlying process issues first, then use technology to support the improved process, not replace it.

I usually recommend that companies take a six-month pause before committing to any major system implementation. Use that time to document current processes, identify pain points, and evaluate whether the problem is actually solvable with technology. Some problems require organizational changes, new training programs, or revised incentive structures. Technology alone will not fix those. Business Driven Information Systems Baltzan provides a solid framework for approaching this topic, but frameworks are not blueprints. They are starting points. The actual work happens in the details, in the conversations with the people doing the work, in the willingness to admit when a system is not the solution. The companies that succeed are the ones that treat technology as a tool, not a strategy. If you are considering implementing a new system, start by asking why. Not what system to buy, not which vendor to choose, but why you need this in the first place. The answer to that question will shape everything that follows. Get that wrong and the rest does not matter. Get it right and you have a foundation to build on.