Introduction to Pragma

Pragma is an Operations Management and systems integration application which adds production management capabilities onto existing data systems, in particular QuickBooks accounting packages.

The primary purpose of Pragma is two-fold: Analysis of time and costs, and Automation of information processing.

1. Provide businesses with tools for analyzing costs and time frames for operations.


The Problem: Many business owners are not accountants – rather, they are experts in the operations of their business. Often, they are skilled tradesmen who have made the transition to entrepreneurship in their industry.

Setting prices for products and services, determining the feasibility of new equipment purchases and other expense decisions requires this analysis of costs, but it is not as simple as it may seem. Many decisions about cost allocations should be made by an accountant, and are based on many considerations that are important, but will always remain in the domain of accounting.

But until the method of allocation is determined, how do you know what to charge a customer for the use of your shiny new equipment? That presents a problem that is unfortunately a significant barrier – it is a barrier to entry into business, and also a barrier to successful business operation.

The problem of cost allocations is just one part of the barrier to entry to business that every potential business owner faces. The first order of the day is to produce a business plan, including a pro forma cash flow projection and operations plan. The cost allocation question is crucial to accurate cash flow projection, so without some way to handle this problem the barrier is quite high.

The Pragma Solution: The central focus of Pragma is time and cost information in the context of production operations. It provides a platform for break-even analysis and price determination, as well as operations management and scheduling.

Another way to describe Pragma is the gap that it fills: Typically, basic Customer information and detailed accounting ledgers are maintained by every company. But everything the company actually does is between these two information domains – the external sales list and deep internal books.

Operations management is key to your success, and Pragma works to give you a coherent basis of information from which to draw for operational decision making.

When the costs are gathered, the work of crunching the numbers and presenting an operations time and cost profile is handled by Pragma.

Pragma does not reinvent the wheel. It pulls data from existing sources, especially the QuickBooks accounting package. It sends scheduling data to calendar programs such as Google Calendar. It does not implement an internal relational database, but can be mapped to read any available data sources. And with access to these data sources, it can be configured to maintain the consistency between different databases and other information stores.

2. Automate the flow of information and document preparation related to operations.


Most operations settings are the source of information for billable activities. A typical scenario is that the operations department sends a spreadsheet with job completion data over to accounting for invoice processing. While it is possible to pull that data into QuickBooks automatically, many users do not have the skill to perform this task reliably enough, so they end up manually re-entering the invoices. Of all the things that have to get done one way or the other, this is at the top of the list.

Pragma provides a platform not only for integrating existing data such as QuickBooks transaction records, but also for automating the exchange of information between systems, and the automatic processing of redundant information-related processes. QuickBooks touts the phrase “Never Enter Data Twice (NED2)” -- and they have done an enormous amount of work to ensure that this promise can be fulfilled by any good programmer.

Leveraging the analysis of operations against QuickBooks features, it is very feasible to build a information-process automation platform within the Pragma framework.

Similar scenarios include production routers and job travelers, inventory checklists, labels, and tags, and virtually any other document type that derives from the various data sources in the system.

Here are some feature lists:

Pragma Performance Features

• Time and Cost Analysis for Business Operations
• Automation of Information Processing related to Ops (Estimating, Invoicing, Purchasing, Inventory Management)
• Produce Production floor routers and traveler with Operations profiles
• Generate Inventory Management documents: Checklists, labels, and materials tags
• Automate most QuickBooks features (they must be customized – not a catchall!)
• Tie Operations data to QuickBooks Estimates for use as Job Templates, and to Invoices for automatic invoice preparation
• Integration with Existing Data Systems
• Example: Complete Operations descriptions tie to Billable Line Items in QuickBooks
• Jobs are made up of one or more Operations (QuickBooks Customer:Job list and Estimates)
• Operations are divided into Activities, or process steps (One Op per QB line item)
• Activities are assigned the Resources they use (Can be QB line sub-items, even if not charged):
• Equipment (pulled from QuickBooks Fixed Asset Items list)
• Humans (pulled from QB Employee data)
• Plant facilities (depends on the plant – probably managed by Ops)
• Direct and Indirect Materials (Inventory and Non-Inventory Items in QB)
• Whatever (Generic Items)
• Resources costs are based on resource type
• Equipment is allocated a portion of depreciation expense or a rate based on replacement value
• Disposable material costs are transferred whole
• Reusable materials are assigned a usage rate
• Payroll costs are assigned directly or allocated based on attention (unattended vs. attended operation steps)

Pragma Design Features

• Runs as a stand-alone application or integrated middleware.
• Coordinates information from existing databases and QuickBooks accounting data, especially Customer and Job lists and Resource costs (QuickBooks Fixed Asset and transaction Items).
• Based on a Business Objects layer that propagates time and cost information throughout the system based on single input sources, either from existing data stores or user entry.
• Integrates with Google Calendar or Outlook for scheduling operations.
• Developed in VB.NET on Windows XP, Visual Studio Professional 2005, .NET 2.0
  

The Pragma User Interface

Shown is the primary user interface to the Pragma application. Click on it for a more legible view. The timeline at the top controls the display of the Operations Activities. The user assigns time to each activity and costs to the resources used in the data grids at bottom. Time and cost data are propagated through the object chain to arrive at various subtotals and the total Job Cost and Job Time (shown in the upper right corner, on the top line next to the timeline).

The context of the screen is a Job. For the job in view, Operations rows are the thick rows just beneath the timeline. Each operation is composed of one or more activities (steps in a process), and each job is composed of one or more operations, all of which are displayed.

Total costs per activity are shown at the bottom of each column of the schedule display.

Costs and time per operation are shown in the columns at the left on the Operations rows.

Resource costs per job (for all operations) are shown in the columns at the left of the Resource allocation lines (thin row lines beneath Operations with a white background).

Although very lean, the data tracked in this framework is crucial to business planning. Knowing costs and their relation to resource use allows a business to properly set prices and control profitability within the constraints of the market. The goal is in fact to allow the market to constrain and guide the business decisions, not to be constrained instead by a lack of information and analysis.

The manner in which time and costs flow through the object hierarchy is what gives this application life. It is hard for me to imagine a scenario where this framework would be insufficient to model the contribution margin and break-even chart for a business project.

Note that this interface is not a calendar, but rather a scheduler. In other words, the time spans shown are not tied to a calendar, but to an abstract time period, ie, any given 12-hour period or year or whatever. Instead of pairs of start/end date-time fields, time spans are stored as single field durations. In that sense, operations that are defined by a Pragma object form the entire detailed record of an event that could be placed on a calendar, where it may appear as a single object. The only difference to start would be that the scheduled event attaches a start date to the Pragma scheduler object.

When a Pragma is defined, it is essentially an estimate, a forward-looking abstraction. When placed on a production calendar and extended to match real quantities of production, the Pragma object becomes a historical record. When placed into a planning calendar and extended for anticipated demand, the Pragma object becomes a part of a cash flow projection.

Time, money, and resources being the foundation of business, this is where Pragma begins.

Description of Pragma

A pragma is not Greek to me, but a very specific type of pattern. Similarly, what I mean by pattern in this context is much more specific than usual. But we will begin with this: A pragma is a pattern.

To fully explore the concept of patterns that I am using, you begin with "The Timeless Way of Building" by architect Christopher Alexander. Then, you note that Alexander's work was enthusiastically embraced by the Object Oriented Development world, a realm inhabited by software engineers and their ilk. So now there are a wealth of web sites and books devoted to the development of patterns for use in software development.

Needless to say, that is all very deep thought. It is fundamental to the meaning of pragma, but there is already so much explanation of patterns and their use in software engineering that I will refer to, and not add to it in this post.

A key sentence from The Timeless Way of Building is this: "A pattern only works, fully, when it deals with all the forces that are actually present in the situation." This sentence was running through my mind in the days that I was working on the Pragma class library.

Typically middleware is developed with a view to the fine-grained details of a business operation and its information structures. By its nature, an end-user database application is idiosyncratic of the particular business. So there is no universal solution for managing business operations.

For a software system to be useful, it must contain a model of the operations it applies to, and so the developer needs a specific conceptual framework to program within. Not just the ideas, but the coded and implemented software objects.

I have always recreated this framework specific to a particular client, but under time constraints, only in the most basic way. Specific operational details within any organization always have to be analyzed individually in context, something that is difficult to do in a general way.

But there are of course many reliable patterns in the specifics that get repeated from company to company. Double-entry bookkeeping comes to mind. There is no one-size-fits-all chart of accounts, but there is a chart of accounts that both models a given business and also meets the requirements of accounting.

For business purposes, the most fundamental information level is the cost object. The cost object is subsidiary to the time object. Time is money, but you can't buy time. For other endeavors, some other basic unit can be associated with time, such as a number of people or objects. That depends on the endeavor. But a business pragma is built on the foundation of costs over time.

The time factor is connected, in business, with operational activities. It is in the activities that resources are used, and it is the resources that drive costs. In an effectively run business, the goal is to minimize activities that are not productive. This means that the important activities are associated with customers by way of the products or services they purchase from us.

And finally we have the relationship over time between customers and our company itself. Now we have traversed a pragma tree: from the measure of costs and the time it takes to perform operations, we create a chain of resources and their costs, operational activities, customers, and ourselves. The hierarchy looks like this:

Company
-Customers
--Jobs
---Operations
----Activities
-----Resources

Typically what I find in a customer's information technology situation is a reliable source of internal Company data, Customer data, and Job information in a database that everyone can access parts of. And all of the information about costs and which resources are on hand is contained in the accounting system, which is behind that locked door in the room with the password-protected screensaver. Not to be critical of these controls, just saying: that's where the needed information is. Control of sensitive information is among the biggest challenges -- it is necessary to share the information, as well as protect it.

As for operations, what I am asked to do has something to do with this area. The production manager has a system of some kind in place, at least a mashup of spreadsheets. But there is a felt need to manage operational costs more effectively, and a desire to avoid redundant data-entry into the separate systems. Operations knows who needs to be billed, and for what -- but they do not do invoicing. How does Accounts Receivable clerk get the information from Ops? Probably in a spreadsheet. Unfortunately often though, on a hard copy.

In a large corporate data center, redundant data entry is not a problem so much as the order of the day. The clerks themselves are the middleware -- wet middleware that ties together the disparate systems in use throughout the company. That is what clerks are hired to do. The fact that clerks routinely go crazy with the insanity of much of what they are required to in this regard is moot. They aren't hired to be happy either. In that case, I am hired to write software that does things too complicated or specialized for a human employee to be tasked with.

It is somewhat different in a small company -- the clerks are often the owners, and they don't enjoy wasting time nor money on redundancy. Or there is a large amount of data that is generated by their operations, which does not fit easily into a standard spreadsheet or simple database system. In that case, we are designing a database application specifically to track that, and only that, store of information.

Another scenario is the bottleneck. There is some desk somewhere with overflowing boxes of documents and many megabytes of raw data in their computer system, with no hope of manually digging out of the hole in timely fashion. Radical measures are deployed in the form of a software development project, and a team of temporary clerks are called in to enter the bottleneck data while a programmer writes code to parse the raw data into a database.

None of these scenarios lend themselves to the development of comprehensive pattern frameworks. Despite seeing so many different operations with abundant similarities, there are also many differences and idiosyncrasies in every situation. So this approach that I am calling Pragma is the result of those years of experience, the extrapolation of the basic necessary information needed to run a business and track its information.

The first Pragma component is an operations management module that organizes production activities for cost analysis (contribution margin and break-even) along a timeline. I had never seen any software do this sort of thing very well. Probably because those solutions so far outside my price range I wouldn't even recognize the neighborhood. Deep calls to deep when it comes to pockets and software budgets.

Coolest thing of all is the availability of the Quickbooks API. This exposes a popular accounting package to my own applications, and the accounting system contains most of the operational data -- just not organized in the perspective of a production employee. In software development terms, Pragma is a business-objects layer framework which performs middleware integration of customer databases, operations databases, and accounting systems.

On Pragmata

"Now faith is the substance of things hoped for, the evidence of things not seen."

Hebrews 11:1, King James version

As a young person I was very religious, and became amazed when I discovered for myself the sometimes terrible results of translation. I was intrigued by the words hypostasis, which was translated as "substance," and pragmaton which are "things."

What better word for the subatomic and quantum realm than "hypostasis"? It is not stasis, but it underlies and provides the foundation for the world. And the hope of seeing it, and of auditing pragmatically the unseen features of the world, is the very mission statement of science. This verse more accurately describes the modern endeavor known as science than it does any mainstream concept of faith.

"Evidence of things not seen" in Greek is pragmaton helenchos ou blepomenon. "Evidence" works, but more literally it is "pragmatic audit of the unseen." Because of the typical fundamental differences between people that may be described as pragmatic and others who are religious, I was also attracted to investigate this Greek work for what, precisely, is to be audited by faith.

The Greek word pragma (πραγμα), plural pragmata (πραγματα), whose root meaning is 'that which has been done, an act, a deed, a fact', and whose connotations and more extended senses cover a wealth of meanings, including: action, affair, annoyance, business, circumstance, concern, expediency, government, innovation, job, matter, necessity, nuisance, object, objective, occupation, office, one's place, role, or work in life, powers that be, private affairs, res, thing, trouble.
"Pragma." Wikipedia, The Free Encyclopedia. 5 Mar 2007, 15:54 UTC. Wikimedia Foundation, Inc. 3 Jan 2008

It is little wonder that this word did not come over to modern English except as the root of pragmatic. It is a bit of a catchall, and it stands to reason that cultures already have their own terms for stuff like this. Such as "stuff." Or "things."

In the context of software development, however, this list of meanings for the word pragma begins to look familiar. Especially in middleware development, where I have spent most of my software development career. In fact, dividing the list up into related categories, I came up with four distinct groups:

1. Corporate (in the sense of collective) endeavor
• business, concern, government, powers that be
  
2. Personal endeavor
• job, occupation, one's place, private affairs, roles, work in life
  
3. Field of context
• action, affair, circumstance, matter, object, objective, res, thing
  
4. Devils
• annoyance, expediency, necessity, nuisance, trouble
  

These are the elements that need attention in order to be effective in the world. This is rather remarkable for a single word -- it outlines the forces in my life, and in the lives of my customers, very broadly, but effectively. How do we meet the demands of the devils, or overcome their influence, in dealing with the affairs of people and interacting in groups?

Emergent Properties and Unintended Consequences

It becomes clear on this examination that "pragma" does not refer to any one of these alternatives so much as their relationships and context. It denotes concern about the details (where the devils are, of course). It is less a word than a concept, and so the fact that is not an English word per se is perfectly appropriate for our purposes.

Leaving the realm of religion and philosophy, a pragmatic audit of the unseen makes a lot of sense in the practical world. It suggests an awareness of emergent properties and an attempt to analyze the probability of unintended consequences.

"Is IT impossible to get right?

"The reason I ask is because of a survey by Tata Consultancy Services. The survey found that 43% of the 800 or so IT managers TCS talked with say their business managers, and even board members, accept problems with IT projects as the norm, as a "necessary evil." And those problems, according to the IT managers, include missed deadlines (62%), cost overruns (49%), and higher-than-expected maintenance costs (47%)." John Stoat in Information Week

Whatever the answer to Mr. Stoat's question, the point I took away from this is not that IT is an evil -- undeniably -- but that it is a necessary one. So necessary that all those problems simply have to be put up with, even in the estimation of the hard-nosed class.

The same question could be asked for the same reasons about business in general: It is impossible to get right? Maybe so, but you've pretty much got to give it a try. And another.

As it happens, there is good reason why business in general, and information technology in particular, are almost impossible to get right. They are as complex as the world is. We cannot hope to solve all the problems and answer all the questions. We cannot know what we do not anticipate.

What we can do, is this: work out a pragmatic pattern for working with the complex relationships between individuals, companies, governments, their stuff, and Murphy's Law.

Pragma Software lives in this domain. I develop tools that use patterns to solve the problems faced by small business owners. If the devil is in the details, then the proof of the pudding is in the eating. Dig in!