As part of the Washington DC Digital Capital Week conference, I was invited to participate on a panel discussing our experiences helping startup and ecommerce organizations with their financial reporting needs. Here's a summary of my comments.
The decision making process is something that evolves over time so itís nearly impossible to create a complete solution up front. The business changes, customers and opportunities come and go, sales and marketing results vary, and the economy and government regulations are always in flux. Itís important to understand what data is necessary to make decisions, try them quickly, then determine what needs to be kept. Different groups may need different information. For instance, accounting, operations, marketing, sales, and management all have different needs for data. For startups, the data is limited and so are the needs. At the most basic, data is necessary for operations and accounting. Over time, the value of data such as customer lists, buying history, marketing response rates, customer churn, etc. become more critical. An organization should naturally invest in better data analysis and reporting when the results justify the cost of building it.
Most organizations start with spreadsheets. Excel remains the most easily used and customizable platform. Most managers know how to use it and it works well because managers can manipulate their data, understand it and customize what they need. However, spreadsheets faces limitations with scalability as data changes. Anyone whoís tried to maintain a spreadsheet over time when new columns and records get added forcing formula adjustments, etc. spend a huge amount of time maintaining these and then make mistakes that result in bad decisions.
The next progression is using a database. Properly designed databases scale very well and support an unlimited number of records. In databases, new records are free but new fields are expensive. With a database, queries and reports can be designed that can be repeatedly run over time. Filters for date ranges, customers, products, regions, etc. can be implemented very cleanly and scale over time. The most popular database in the world remains Microsoft Access and many people who are comfortable with Excel can use a Microsoft Access database to create ad hoc queries, filters, and reports. We would recommend an experienced database designer to make sure the database is designed properly so it scales over time, but Access allows non-programmers to easily manipulate their data and export it to Excel for additional analysis. Database developers can also write code to generate more complex analysis. In many organizations, data from larger systems get imported into a local copy of Access for analysis and reporting. Access also offers the additional feature of being able to link directly to other data sources such as SQL Server, Oracle, and MySQL. This allows using data beyond the 2 GB limit of Access databases.
As the data needs evolve, organizations require more sophisticated systems and can justify the additional cost of doing so. With data in an enterprise platform such as SQL Server, business intelligence tools and reporting services provide additional ways to slice and dice data. Custom reporting applications can also be created to produce reports that are available for internal and external (customer) needs. Integration layers between external vendors may be necessary, etc. At this point, itís unlikely the decision makers (managers) will be able to create their own solutions. Professional developers get involved to design and create the output, and the cost and time it takes to create each report is significantly higher and less exact. That said, data should still be possible to export into a platform like Excel or Access to perform unplanned analysis.
Enterprise software solutions should provide institutional (ďcannedĒ) reports and systems that managers can use, and give them the data they need to perform their own analysis since theyíre closest to the action. One can expect that over time, some of their analysis become mission critical and should graduate to the organizationís main systems. Some organizations resist this architecture because they want to create and control systems centrally and have the IT department do all the work. What they miss is that by empowering information workers to do their own analysis, the natural evolution of decision making is supported.
A healthy organization acknowledges that their reporting and analytic needs will never be finalized and must change over time. When managers "design" what they want, it often changes when they first see it. This is not because the manager was being difficult but because people often don't know what they really want up front. It's an iterative process, which is terrible for traditional application development.
Experienced developers also recognize that many organizations create expensive solutions that are poorly received or under-utilized, so its important to minimize these situations. It's always possible in hindsight to say a particular piece of work could have been done more cheaply if it were done "the right way" by professionals originally, but that addresses the issue backwards. By letting people create their own analysis quickly, cheaply, and fail cheaply, the limited and expensive IT resources don't need to be involved with a vast majority of this in-process work.
Most analysis is simply analysis and goes nowhere. It's trial and error. Itís a rare piece work that becomes mission critical. By focusing the organizationís IT resources on institutionalizing whatís actually proven and using cheaper methods for less critical work, the entire organization can go after opportunities at a lower cost, not give away business to a competitor, and gain a competitive advantage.
Here are some additional resources that may be helpful
Thank you! Thank you! I just finished reading this document, which was part of a link in the recent Buzz newsletter. I have printed it for others to read, especially those skeptical on the powers of Access and its capabilities.