Make Mine MAPPER #11 --------------------- by Rob Haeuser MAPPER: The Perfect EIS Environment, or EIS: Acronym In Search Of An Application --------------------------------------------------------------- During a conversation the other day, someone made the statement: "...and this company has an EIS package that anticipates the needs of every executive ever born...". Or something like that. I thought: Great. Just what we need, another new acronym. What does it stand for? And how do you pronounce it, "ice" or "eyes"? Both can have negative connotations when associated with executives, you know. What is an Executive information system, anyway? EIS is actually a new label for an old concept: to provide management with useful, timely information that can be used to facilitate sound decisions. The current twist is to create an environment where all information is presented in a concise and consistent manner. Color monitors, graphics, and the PC "look-and-feel" are becoming common. It is no longer acceptable to plop 5-inch-thick reports on a manager's desk and expect to retain one's job. Call it manifest destiny. It is as if MAPPER has been groomed for over twenty years for this very concept. "MAintain, Prepare, and Produce Executive Reports" sounds like another way of saying Executive Information System, doesn't it? We are all familiar with MAPPER's rich functional environment; it's support of color monitors and graphics, all required for any plausible EIS. So how would you go about doing an EIS in MAPPER? One problem with developing an in-house system may crop up at the very beginning. With most systems, I immediately identify a "key user". This person decides what functionality is required and has approval authority. The relationship with the key user can get quite interactive and intense. Of course, the key user of an EIS is the chief executive, the company founder, the director of the board, the president, or some equally antagonizing figure. These people tend to be very busy, and may look upon the key user role as something to be delegated. This can be disastrous if not controlled. You must make the boss understand the importance of one-on-one interaction at a moment's notice. If the key user role is to be delegated, the boss should still be present for all initial meetings, so there are no major surprises later. So, you're lucky. The boss wants to be involved. Don't let the idea that your job may depend on this one application intimidate you. Look at it as an opportunity for personal recognition. Treat him just like you treat all your other users, maybe worse. After all, he's probably DP illiterate. And that's the next big problem. After a couple of minutes into the first meeting, you may notice that EIS has taken on new meanings. "Gee, will this system give me Everything In Seconds?" Well, maybe. "No matter what I ask for, it will be Exact, I'm Sure." Not unreasonable. "All the data will be Entirely In Sync." Sure hope so. "Then this EIS is really an Eclectic Idea Solidifier!" Huh? Try to nip unreasonable expectations in the bud. It helps to spell out some of MAPPER's capabilities, especially in regard to data retrieval and manipulation, including the manual functions. This can really help direct the development process. At this point, EIS should be treated just like any other application. Identify data groups and elements. Where is all this data coming from? The ultimate dream is that it resides inside existing MAPPER applications and can simply be tapped at will. Not likely. Data will probably come from various sources, and may include DMS1100, RDMS, and MSAM file applications, as well as strip files, etc. And the further the data is from MAPPER, the more dated it becomes. The timeliness of information is a critical concept. It will probably not be possible to provide instant, real-time, "everything in seconds" data for all occasions. This should be clearly understood. Some aspects of the data may be real-time, while others may be hours or even days old. The nature of your business should dictate how close to real-time you need to be. Let's look at a "typical" MAPPER Executive Information System. Since you recently discovered the true power of the screen control (SC) run command, you can create color screens with function key bars, giving the system a consistent "look and feel". When the system is executed, the first menu might group the data into general categories, such as "Personnel", "Payroll", "Inventory", and "Orders". After making a selection, a second menu might list more specific categories, such as "Personnel above pay-group NN", or "Personnel that I don't like" (look out for that one!). There is theoretically no limit on how many menus and sub-menus can be connected, but try to keep it fairly "shallow", going no more than two sub-menus deep from any one menu. With the final data request in hand, the run now decides where that data should be. Is it in a rid that has already been created? If so, graph and display it. Best case of all: Is it data that has already been converted to primitives by a graphics run? Simply display the graph via @DSG (display graphics). Is it in an application running on another MAPPER? You might start a remote run (RRN) to retrieve it. What if the data is in a DMS1100 application. You could access that database via MAPPER's TIP interface, starting a pre-defined TIP program to conduct the database extraction, passing the data back to MAPPER for further processing and display. The same process could be used for any data file structure accessible via TIP, such as MSAM. You may need to solicit the services of a TIP programmer for data from this environment. For data in a relational database, such as RDMS1100, you can use the MAPPER Relational Interface (MRI). Again, data will be returned for further processing. The data can even reside at the PC level in a DOS file. File transfer utility runs provide a file upload capability, placing data into a result that can then be manipulated. The data can reside in many different places, brought together under the MAPPER umbrella. It can be presented either as listings or graphs. It can be as real-time as circumstances allow, or as dated as your chief executive will tolerate. This is great for the "What's going on?" type of question. But what about the infamous "What if..."? This is where MAPPER's many functions come into play. "What if I excluded this widget type?" Search. "What if I wanted to see this years data first?" Sort. "What if I lump all of these together?" Totalize or calculate. Of course, the questions can go beyond using built-in functionality. "What if I don't like the color of the function bar on the menu screen?" Even that can be handled. The "What ifs" will tend to drive the complexity of the system. So far we have assumed that all aspects of the system are handled by MAPPER run functions. This gives the most professional appearance, but requires that either all questions be pre- determined, or that your run code is extremely flexible and clever (not impossible, but often difficult). A minimum understanding of manual MAPPER functions can give the executive a completely different perspective of the data, one not previously anticipated. Therefore, it is important to know very early in the development process how much you can rely on manual functions. If you get a negative response, drop it and start coding. Make allowances for adding "What if" capabilities as needs are identified. If nothing else, you can count on a constant stream of suggestions. An EIS system can go beyond providing snap-shots of data. It can be interactive with the systems that feed it, directing entire processes in such a fashion as to give the executive true control over the environment. That may be the major drawback of a truely interactive, synergistic EIS: the tendency to encourage micro- management. Ultimately, the success or failure of the business (maybe even the government!) could depend in large part on decisions made from information provided by an EIS you write. That sounds like a strong argument in favor of buying a canned package. But canned packs have their drawbacks. All companies and government offices are not run exactly alike by people who think exactly the same things. In reality, it is a rare canned EIS package that gets implemented without extensive local modifications. Why run out and buy the first canned EIS you see? They are not cheap, and you might already have one in-house, just waiting to be accessed.