Monday, March 15, 2010

Chapter 2 - The Events Leading to DecisionPoint

The story of DecisionPoint actually begins long before the company was founded. In May of 1988, I joined a large computer hardware engineering and manufacturing company based in the Pacific Northwest, Sequent Computer Systems (Sequent). At the time, I was assigned to help support their ASK/MANMAN system along with some other tasks in their Information Technology group. Shortly after I joined Sequent, the decision had been made to transition from ASK/MANMAN to Oracle Applications, which was software designed to support the accounting and manufacturing processes within a company. Oracle Applications was under development at Oracle, and Sequent was acting as a partner and the first alpha/beta site in testing the Finance, Manufacturing, and Distribution components of Oracle Applications. I was literally the first technical person outside of Oracle to ever work with Oracle Applications. Between 1988 and 1990, Sequent implemented the General Ledger, Accounts Payable, and Fixed Assets modules of Oracle Applications. The other finance modules would not be implemented until Sequent was able to convert to Oracle Manufacturing. In April of 1991, Sequent implemented all of Oracle Financials, Distribution, and Manufacturing in a production environment using the “big bang” (turn everything on at once) implementation approach. As far as implementations go, everything went relatively smoothly. The process of testing the software and converting historical data was long and tedious, but we had an excellent team and excellent plan.

As a sidebar, I was also leveraged as a resource to the Sequent sales force. My role was to help them sell Sequent hardware to run Oracle Applications. I took my practical implementation experience, and shared it with potential customers. This included traveling around the world with minimal notice to help in a variety of sales situations. In one instance, I had one day’s notice that I was headed to Hamburg, Germany with no idea of when I would be coming home. At the time, our oldest child, Andrew, was barely two years old. This meant for quite the juggling act trying to keep a computer system alive within Sequent, traveling to help the Sequent sales force sell hardware, and manage staying connected to a young family. Somehow I made it work, and it paid off both professionally and personally.

From a personal perspective, I got nice raises, stock options, and worldwide recognition as an expert in my field. In one year, we were able to close $30 million worth of hardware sales related to Oracle Applications. On top of everything else, I was able to win the Sequent “Employee Excellence Award” twice. This award was given to non-commission based employees, and the person had to be nominated by their peers with final approval by management. I was most proud of these awards as they were from my co-workers, not necessarily management. My co-workers understood what I was up against in my juggling act, and did a fantastic job supporting me in my multiple roles.

Back to our main story…

One of the goals of Sequent’s CFO for implementing Oracle Applications was to have better and faster access to information. Better and faster access to information was not achieved by simply using new and improved reports within Oracle Applications, but rather the ability to take that data and perform higher levels of analysis. The reports within Oracle Applications were adequate for running the operations of Sequent, but there was not much available for users in upper management and at the executive level to make strategic business decisions and course corrections. While the technology of Oracle Applications was more open and flexible than the old ASK/MANMAN system, getting information out of Oracle Applications in a way that upper level management and executives needed to use it was still difficult.

I remember a conversation that I had with the CFO at Sequent at the time. We were in a meeting to discuss what his vision was for the type of access and analysis he would need to better run the business. He relayed a conversation that he had with Oracle about the topic. His comment to Oracle was “You promised me great and flexible access to all of data that I’ve never had access to, where is it?” Oracle’s response was “It’s in there…you have to figure out how to get it out…” I’m sure there was much more to the conversation than what he relayed to us in the meeting, but that kind of sums up Oracle’s answer at the time. At that point, Sequent’s CFO would make a decision that would significantly change the course of my career over the next several years.

In the winter of 1991, the CFO of Sequent tasked me with figuring out a way to get the information out of Oracle Applications into a “usable form”. When the CFO talked about usable, he would jokingly say “if it has more than one button, I won’t be able to use it.” That was definitely an exaggeration on his part, but what he really meant was that it had to be simple to use, while at the same time providing maximum access to information. Having him, or any other executive at Sequent, learn to login to Oracle Applications and run inquiries and reports was not the right answer. This would have meant that they would have to learn a complicated application that they wouldn’t use that often, and that would not provide data at the summarized level they were looking for.

Around the same time, Sequent was trying to change the way that it was doing business. Traditionally, Sequent sold computer hardware to large companies. They left the job of software delivery and implementation to the customer or to consultants that the customer was willing to hire. Sequent decided to change course a bit, and made a bet that they could get into the consulting business so that they not only delivered the hardware platform, but could also get into the business of software implementation on top of that platform. Along with this, Sequent began to invest in developing software that would be layered on top of the Sequent hardware to make the hardware platform and associated software easier to implement and manage. The goal was to deliver a targeted set of software and consulting services that would add value to any customer implementation of Sequent hardware.

Sequent decided to create an entire new division that was focused on software development and implementation. The goal of the new division was to be able to make decisions somewhat independently of Sequent’s traditional hardware business. Given that the new business was in software and implementation, Sequent’s existing processes around the hardware business would be insufficient. Therefore, the new division was formed to focus on this new direction. Within the division, there were four primary areas that Sequent wanted to focus on. These were all areas that Sequent had strong existing expertise in.

The first area was an area known as enterprise architecture. Up until this point, Sequent customers would acquire the hardware platform, and then independently implement different software solutions on that hardware platform. Over the years, many customers had acquired multiple hardware platforms and software solutions. The goal of the enterprise architecture group was to help the customer come up with an overall strategy on how to manage all the different platforms and software solutions, and then produce a roadmap for how the customer should move forward when it came to future implementations. The goal was to get the customer out of the mentality of simply acquiring a new hardware platform every time they wanted to do something new, and get them into a mentality of acquiring the hardware with the goal of simplifying their computing environment in order to make it easier to manage.

The second area was targeted around online transaction processing (OLTP) applications. These applications had traditionally been the bread and butter of Sequent’s business. The Sequent hardware platform was outstanding at supporting hundreds or thousands of users entering specific transactions. When I say specific transactions, think of something as simple as entering a vendor invoice or purchase order. Part of this area of the business involved Oracle Applications, which Sequent’s IT team had deep experience working with. In this area, Sequent was not necessarily going to deliver any software. That was already handled by the software vendors. However, what Sequent could do was take the rich experience and knowledge that they had gained from implementing Oracle Applications internally, and building a consulting service that could help customers do the same type of implementation.

The third area was targeted around systems management. Similar to the situation for enterprise architecture, when a customer acquired new Sequent hardware, they would simply plug it in next to the existing hardware, install the software, and let end users begin using it. The problem was that each hardware platform was managed independently of the other hardware platforms. If a customer had ten Sequent computers, they would have to login to each system separately, and setup things like backup, etc. Sequent’s goal was to partner with existing software companies and build some of their own software to be able to manage the hardware platforms from a single location. Rather than login to each server, there would be a central console that would manage all the servers. So, if you setup something like backup on one of the computers, you could easily deploy that to the other computers in the environment without having to login to each one and do the same thing over and over again.

The fourth, and final, area was targeted around data warehousing. Up until this point in time, the data warehousing market was largely dominated by companies like Teradata and IBM. As described before, conceptually, data warehousing represents the consolidation of large quantities of data (millions or billions of transactions) to make it easier for end user to analyze the data for making strategic business decisions. Sequent was beginning to get into the data warehousing space because companies like Oracle and Informix (now part of IBM) started to make their software better able to handle the quantities of data required by a data warehouse implementation running on the Sequent hardware platform. Sequent had performed a couple of successful data warehouse implementations for different customers, and wanted to take that experience and knowledge to help other customers deliver data warehouse solutions to their end users.

Of all of the areas that Sequent was about to get into, data warehousing was probably the most promising as far as future business growth. It was a new market that Sequent was having early success in, and more importantly, it required very large Sequent hardware platforms to deploy the size of data warehouses that the customers needed. The other areas would drive moderate growth in the sales of hardware platforms and services, but if done correctly, the data warehouse area would represent the largest potential for growth. In many ways, it represented the future of where Sequent would draw most of its revenue from.

Because data warehousing represented the “next big thing” for Sequent, a lot expertise in building data warehouses and working with data warehousing technologies was developed. With my new project of implementing a data warehouse for use internally at Sequent, I was able to tap into great sources of expertise, and leverage it to help me design and build a data warehouse for Sequent that contained finance related data (General Ledger, Accounts Payable, Fixed Assets, Accounts Receivable, Order Management, and Purchasing) coming from the Oracle Applications installation. At the time, there were a lot of moving pieces in the data warehousing market. There was a whole new set of rapidly changing technologies, philosophies, and implementation methodologies. Without having to blaze the trail myself, I could leverage the collective expertise of data warehousing knowledge within Sequent to figure out the best way to move forward. It definitely made my job easier as I could focus on the implementation rather than trying to chase down and experiment with the latest and greatest new technology fad.

Rather than go through the details of each decision I made, we ended up implementing a data warehouse on top of the Oracle RDBMS running on a Sequent platform. These choices were easy because they were both technologies that we had experience with. We did experiment with one other database technology called Redbrick at the time, but we had no experience with it, and it would have represented significant changes to Sequent’s internal IT environment. At the time, there was no budget for additional software or IT resources to support the software, so we went with Oracle. As far as end user access to the data, we went with two different sets of tools. The first tool was Pilot Lightship, and was classified as an executive information system (EIS) tool. Its job was to provide summarized data to Sequent executives in a very easy to use format. All of the questions that executives wanted to ask were predefined, so it was a bit inflexible, but it was extremely easy to use in that most interaction involved a single click of the mouse. The second tool was called Clear Access and was designed for adhoc access to the data. Users could literally build a query to answer any question that they wanted, but it was somewhat difficult to use, and required that the user had pretty intimate knowledge of database tables and columns. It should be noted that both tools would be considered sub-standard in today’s world of data warehousing, but at the time, they were state of the art.

In the winter of 1992, I delivered the data warehouse to end users, including executives, cost center managers, sales management, and financial controllers. As stated above, the data warehouse was built on top of an Oracle database using a home grown Extract-Transform-Load (ETL) to extract data from Oracle Applications and load it into the data warehouse. The majority of the end users were given access to the data through Pilot Lightship with just a couple that had access through Clear Access.

There were some bumps in the road during the implementation as end users were uncertain of the accuracy of the data. It turned out that some of the revenue information could not simply be extracted from the source system due to the way that Sequent accounted for revenue in their international division. Sequent’s process was for headquarters to build, ship, and invoice the Sequent subsidiary in another country for the hardware, and then the Sequent subsidiary would ship and bill the end customer. There was limited correlation between the revenue information in the Sequent headquarters system and revenue coming from Sequent’s systems supporting the subsidiaries. We eventually had to build a series of complicated processes to merge the data, which included a couple of screens that allowed specific end users to make changes to how some of the data was merged. We worked through those issues, and eventually got the end users to sign off on the accuracy of the data.

Because Sequent was a beta site for Oracle Applications, Sequent would actively host Oracle’s prospective customers and do references for Oracle Applications. These were sit down Q&A sessions where individuals within prospective Oracle Applications customers could sit down with someone within Sequent who was equivalent to them in position, and talk about how their job would change, etc. These were typically all day sessions with separate meetings and breakout sessions. The Oracle Applications prospective customers were facing significant changes in how they would end up running their business, and Sequent was a good resource to help them talk about and work through the changes.

The Sequent CFO was very proud of what we were able to accomplish with the data warehouse I had built, and the types of access he had to information. Therefore, during the executive sessions of these meetings, the CFO of Sequent would proudly show the data warehouse environment that he was using. Given that the prospects we were talking to would be new Oracle Applications customers, when we talked about the data warehouse, we talked in terms of the types of things that you could do with the data after you implemented Oracle Applications. It was clear to the visiting executives that implementing Oracle Applications could help them springboard into other technologies, like data warehousing. As a result, almost every visitor that saw our data warehouse implementation would comment to the CFO that if they bought Oracle Applications, they wondered if they could also “buy” the data warehouse environment that I had created.

Over time, given the interest level of prospective Oracle Applications customers, and the fact that Sequent was making a big push into the data warehousing market, it was clear that if we could turn the data warehouse I had built into a commercially available piece of software, there was a market for it. Sequent’s CFO and I talked, frequently, about the possibility of Sequent branching out into the applications software market with the data warehouse solution. However, it was not an easy thing to do within Sequent. While Sequent was starting to get into the software market, it was strictly around tools and utilities to make the Sequent hardware platform easier to implement and manage. There were never any discussions or plans around application software. If we were to do this, we would have to try and accomplish it with minimal impact to the rest of Sequent’s organization. This would prove to be difficult for many reasons as delivering application software was much different than what Sequent had traditionally done.

Eventually, in early 1994, and as more prospective Oracle Applications customers came through Sequent, the interest in our data warehousing solution became much higher. Sequent was ready for us to break out into our own small team and start an applications software division within Sequent. In the spring of 1994, through a series of events, the CFO of Sequent decided to assign me to take the internal data warehouse (very specific to Sequent) and a small engineering team, and turn it into a solution that Sequent could sell as a product offering. The product offering would be called DecisionPoint. There were a lot of peaks and valleys in the process because we were very different from Sequent’s traditional business model and delivery mechanism. However, after approximately a six month development effort, we had completed turning the internal data warehouse solution into a product that would auto configure to support any implementation of Oracle Applications at any customer site.

On the sales front, we had a great start even though DecisionPoint represented a new software offering from a hardware company that had limited experience developing application software. We sold the DecisionPoint product to three different companies (two in the US and one in Australia) within the first three months the solution was available to customers. At the time, Sequent did have a consulting staff, but most of the consultants were familiar with hardware and database technology, not application software in the data warehouse market. More specifically, very few of them had experience working with application software like DecisionPoint, so even though we provided some training on our software, I spent a lot of time traveling between our US customers making sure that everything went smoothly. Our resource in Australia turned out to be quite a find, and with some support from our engineering team, she was able to implement DecisionPoint without any of us having to travel there. Overall, while the implementations were a bit painful, they were successful and the solution was used at each of the customer sites. It was a better start than any of us could have imagined.

One of our biggest challenges from a sales perspective was that given that almost all of Sequent’s sales were related to computer hardware, the sales force had a difficult time selling a software solution like DecisionPoint beyond the three initial customers. There were a lot of different factors that caused the lack of sales. However, I believe that at the end of the day, the biggest factor to the lack of sales had to do with DecisionPoint being a small software offering in what was predominantly a hardware company. A sales rep would have to sell ten copies of our software to make the same commission as they would get in selling one hardware platform. The odds were definitely not in our favor.

In spite of the lack of sales, the engineering team continued to improve the product and deliver new features to the existing customers. I was able to shield the engineers from the ups and downs of the sales process so that they could stay focused on getting our product releases out on time. At times, it felt much like combat where the opposition would throw a grenade, and I would jump on it to protect the engineers from getting injured or killed. It was definitely a learning experience that I still carry scars from today.

After a lot of thought and deliberation by DecisionPoint team members and the CFO at Sequent, who was our chief sponsor within the organization, it was decided that being a software group within a hardware company was detrimental to maximizing our potential. What we really needed was to be able to be independent of Sequent so that we could branch out on our own, and pursue the options we needed to pursue, like porting our solution to non-Sequent hardware platforms. We began to investigate what it would take for us to become our own entity, and be free from the restrictions we were under at Sequent.

No comments:

Post a Comment

Visitors

HTML hit counter - Quick-counter.net