Evan Schuman's StorefrontBacktalk

Companies are starting to dip their toes into an “Integrated Information Supply Chain.” But I am not currently aware of anyone doing it on a massive scale. Why aren’t companies moving faster? How do you take billions of retail transactions, millions of billions of social media interactions, millions of marketing impressions and hundreds of thousands of operational statistics and merge them into a set of tools that provide the right people with the information required to maximize their impact on the business? That is the million dollar question.

Today, companies will normally implement functional applications that service some form of business process within the enterprise. These tools will often create a large amount of data that is valuable to someone outside of that functional area. An example is the sales transaction data that is a by-product of ringing sales. Operations, Marketing and Finance often live off of that data. In the future, the success or failure of companies to leverage this data will be largely driven by the planning they put into their Information Supply Chain.

Great companies need to design, build and manage how data will be consumed within their organization and then structure everything else around that. IT teams need to start thinking about the data first and then think about the process/workflows. The questions will be: “What other roles in the company will need the data that is entered into, or created by, this application? How can we get them this information in a meaningful way?”

For the past few months I have devoted a significant amount of my time to designing a holistic information architecture and Information Supply Chain for FOCUS Brands. Even in a midsize company like FOCUS Brands, this task has proven to be extremely difficult. It basically means we are defining each data element within the organization, who owns it (systems and/or persons), who needs it (systems and/or persons) and how change will be managed. Once we have that aspect completed, the next challenge will be in designing systems and processes to enable that information architecture.

My biggest realization in this process is that information will become far less “native” to specific applications and more “shared” across the enterprise. The name of the game is publishing data to the enterprise bus that is then consumed by other systems that subscribe to those updates. Data typically confined to a functional application will be extracted into a separate system to better facilitate data sharing.

It also means that application projects will significantly increase in scope. Instead of evaluating an application against its ability to meet the business and functional requirements, technical requirements (such as information architecture) will start to take center stage in product evaluations. “I understand that your application can meet our supply chain needs, but do you integrate with BizTalk for third-party data storage and access?” This should be fun.

The other big challenge will be in designing an information architecture that allows the data to be extracted as the business needs it. How many different data sources are needed to pull in the list of Facebook fans who visit at least once a week, respond well to E-mail coupons and live within three miles of the location that has to move five cases of chicken by Friday? Is it even possible to design a system where that report can be run in a reasonable period of time? Oh yeah, and can it support franchisee self-service to run a report for just their locations?

By the way, here’s my Term Of The Week: “Ridin’ Dirty”–IT slang for a location that is not PCI compliant. “That restaurant is ridin’ dirty.”

What do you think? Leave a comment, or E-mail me at Todd.Michaud@FranchiseIT.org. You can also follow me on Twitter: @todd_michaud.

Want to follow my Ironman Training progress? Read more at www.irongeek.me.