On enterprise IT adoption in Chem engineering firms (by Kinshuk Adhikary)

Financial companies were the first ones to adopt IT on a full scale. It is heartening to note that companies involved in Energy, EPC and Chemical engineering are exploring IT and software to increase competitiveness and stay in business. Various blogs and forums indicate this trend.

As a former Chemical Engineer with a decade of EPC experience (and another decade of core software applications experience), I am fortunate to have a unique dual view of the whole thing. I certainly can hope that the below observations will have validity.

First, let us discuss a diagram : I often recall (with a feeling of horror) a diagram that I was once shown by a Chief Software Architect. (in a $ 2-billion company that operated in 30 countries and had diligently practiced IT for about 8-10 years). I am often forced to remember it, as part of my toolkit.

This huge diagram had 100 boxes and 500 line arrows criss-crossing. And the Chief Architect was in tears – he had been asked to (a) make sense of the system, and (b) improve it, so that it came under better management control.

Too little architecture, too late : Nimble competitors had been exploiting data analysis tools and making hay, while this giant, literally sitting on a mountain of exploitable data, watched helplessly because its sub-systems would not talk to each other. Good architecture was missing, and it was too late to do anything about it.

Continuous climb : Financial companies did become early IT adopters, of COBOL based systems. The machines and programs were quite good in silos – and most financial companies never moved further – while their faster compatriots built “fully automated stock trading systems which do a million buy-sell decisions in the first few seconds after the stock market opens”. Seems like it (IT) is a continuous climb, the winners being often the cubs, not the lions.

The future is here, in the new generation : The mind-set changes needed for a sound IT adoption flow from one and only one source – an urgent understanding that “a new generation is emerging, quite different from the old”. When this understanding permeates every echelon of management, and the lives, habits, mores of young and very young workers are considered – only then the direction becomes clear and decisions become easy.

May sound philosophical but that is it, companies ignoring this often win the battle and lose the war. The brave new generation have some attributes, like –

• tweets (140 chars) have replaced blogs > have replaced novels, i.e shorts spans, personalized• the work-home boundary is paper thin, home-work (and video games) is done at office and office

work is done at home. The days of uninteresting applications seems numbered.• gadgets are like their arms and legs, so every gadget has to be considered• knowledge is an external repository, open, free. Only workflow and decisioning is human.

What works ? : Consider a very common application – timesheets. I have in my career implemented god knows how many timesheet apps. Only one was well liked , well used,, and successful from a management standpoint.

From the outside, this app was just a small icon that one could carry on desktop, mobile, blackberry – clicking it would open up a single text box – user would enter a few loose lines of text about the task done. That was all. The rest of the inferences the machine made by itself – rarely would it need to ask “start time, end time” - all that baggage. It took quite an effort to build that, but it worked best of all timesheets I have ever seen.

Here are two examples of modern applications that combine a sense of playfulness and seriousness , and high technology – a TO-DO list at http://voo2do.com/, and a travel site at http://www.ixigo.com/

So what would Chemical engineering and EPC firms really need ? Same as others – minor diffs.– ERP-like systems for financial, sales, CRM, HR, production, materials, and so on.– Related local systems or modules hand-built at satellite and branch offices, talking to the main– Analysis and decisioning tools, reports and dashboards for senior management– Document management, knowledge bases, wikis, e-Learning apps, content creation tools– Collaboration suites for various local sub-domains, common messaging platforms– Custom tools for chemical engineering, process workflows, engineering workflows, drafting– Project planning and estimation systems– Task and review tracking systems, time trackers, preferable if integrated with the above five– Mobile applications for on site personnel

How to avoid 100 boxes and 500 criss-crossing lines

• ERP : The jury is still out on ERP systems, COTS implementations. The best bet seems to be to avoid extremes of ERP implementation. ERP systems tend to become monolithic, their individual components cannot be thrown out and replaced. Because business scenarios change too swiftly, very often the people maintaining such systems re-write the whole code once or twice over.

• Export-import : Any sub-system that cannot integrate with its neighbors and/or superior apps is nothing better than a COBOL toy or an Excel macro. That implies that irrespective of how the above list is finally implemented – (a) there must be an “export” option (b) there must be an “import” option.

The life cycle of useful apps is almost Darwinian. Only those survive that manage to integrate with their overall electronic environment, because their usefulness spreads into other systems.

• XML : The export-import i.e. “talking between systems”, should be in XML – since XML is the only standard that all machines understand (or ought to at least, in 2009 A.D).

• DSL : The language can be XML, but the dialect (ML = markup language, DSL = domain specific language) is crucial too. This babel problem only financial companies have overcome – a Chemical engineering company cannot talk to another because there is no universal standard to describe , say valves, reactors etc. Most companies define their own DSL internally – this is a slow process but unavoidable. Eventually the best DSL in the market survives.

E-learning systems without an IMS or SCORM capability today cannot be imagined – the vast mass of content creators follow these specifications and keep them alive. This is however not true for 90% of the other enterprise tools and technologies, and best dialects are still awaited.

• Sacrosanct uniques, repositories : one database, one knowledge base, one rules repository, one domain language. There cannot be two, or many. This is of course highly theoretical, but it is important to keep in mind while designing the architecture. Imagine two Googles :-)

• Latest stuff : The last ten years have seen an explosion of business technologies and terminologies – I have explained some of them in my blog here. There are also Gartner trends – ignoring such trends, howsoever faulty they be, is risky.

• Paradigm shifts : occur every 3 years, anything older than 3 years – knowhow, college studies, development tools – is automatically suspect. Things change beyond imagination. A tool like IronSpeed (600$) or Drupal (free) can create an application in minutes for what used to take months or even years to do. However, at the very fundament, at architectural levels, the changes are not so dramatic.

• What is enterprise architecture ? An appreciation of this can help avoid many pitfalls. It is a more abstract (and therefore durable) way of solving a problem. It has 3 levels – the pure business problem, the software application problem, and the network and infrastructure problem.

• Most IT efforts in enterprises are intended for some fairly common high level endpoints :• Management visibility, the CEOs dashboard, the company health meter, metrices• User empowerment on a large scale, irrespective of distance boundaries• Knowledge capture and storage outside of humans, for continuance reasons• Decisioning rules, common storage and manipulation• Forecasting and trends analysis• Organizational skill growth, skill-competency and evalutions

• Intrusion factor : Most applications intrude, irritate users, involve learning curves, take more time when they should be taking less, create information overload, generate tonnes of messages etc. Good application building is incredibly difficult, and lazy developers with low levels of user empathy or technical knowledge often create bad applications. In the end only a handful of applications truly make a difference.

• User empathy : Most applications are designed by developers and for developers, and they lack a certain quality of empathy. Typically, unless a piece of software has been (a) tested by millions of users, and (b) undergone at least 3 full-scale re-versionings, it is usually error-prone and generally a drag on efficiency.

Primer for software developers (when talking to chemical engineers) :

– developers ought to understand that Chemical Engineers esp. have a very good understanding of key terms like – process, feedback, control, instrumentation, trees, branchings, joins, structures i.e. things that the IT applications world is only now beginning to play with.

– as an user group, they understand “changes in inputs and corresponding changes in output, with a black box in between”. This makes it easy to convey IT concepts

– most of the chemical engineers work is a taskflow or a chain or a process – and sometimes just configuring an issue-tracking-review system to their custom vocabulary is all that is needed

– they DO NOT understand databases, relational pieces of data, and they think Google and wikipedia are “databases”. Most users also think that the screen is the database.

– they think Excels spreadsheets are meant for engineering calculations, and the concepts of forms, http internet, persistence, data acid-ity and transactions – are not their forte.

– the chemical engineers world is all about - a mass of lines and pipes and instruments and vessels, a finite set of attributes around each. Often the internal formulae of small calculations are immaterial, what matters is that they all work together and deliver a big set of data. This is easier to say than to do, because units of measurement differ drastically between those calculators, moreover the sequence of calculations and recursion convergence is important.

– the big set of data generated by chemical engineers is primarily needed for cost estimations, project progress evaluation, and further engineering

Primer for chemical engineers when talking to software developers:

– engineers in general need to be aware that things have changed since FORTRAN. (sadly, my own wife who is also a Chemical engineer, still thinks that “software” mean “calculations”).

– software is all about “preserving the state of an universe of data, after due transformations”.

– data is numbers, or very small pieces of text – not what you get from Google or wikipedia. What you get from Google and wikipedia are “documents”, or links to documents. Documents have the following things – they have versions, they have structure, and they may contain data.

– excel sheets with macros are fine for working alone at home and producing a report or a chart, but not for collaborative preserved working. Such collaboration can be done if one single copy exists and can be shared over the web, but the moment you create and save a new copy, you are breaking some fundamental rules about the sanctity of data

– in todays world, only web based systems, or those which draw data from a single repository (database) are relevant. Multiple copies of anything are evil.

– do NOT get dazzled by any software – treat it like pencils or staplers, tools to be used for a bigger purpose. Most software is faulty and bad, including the ones that send people to the moon. The increase of errors versus complexity is a mathematical certainity, something like Heisenberg'sprinciple.

– all engineers can understand software, and most software is easy to adopt when you treat it with contempt and understand how incredibly dumb they are at the back of it. Most do this - accept data (from you), put data into properly organized cabinets and racks, and fetch it to show, with some minor changes in between. Ditto for facebook, tweeter, everything, everything.

– emails longer than 140 chars are a time waste, even dangerous for formal enterprise communication or record keeping. They cannot ring a bell, alert you, like chats do, and moreover emails are headless. Anything that is not classified into categories and under control of some higher set of rules is useless, it is only when communication messages live within another system do they become useful.

A day in the life, in a highly automated workplace

(Actually, I haven't yet seen a non-software company doing the things below. Most knowledge work today centers around the production of good quality documents, which is what a software company also does, so it should be relevant).

The fundamental and smallest unit, around which the entire system revolves, is an atomic “task”.

• Worker (everybody is one) logs in to system. Does NOT open the email Inbox. Instead, a tasklist dashboard opens up, showing pending tasks, urgent messages, news feeds etc.

• Worker sorts, searches, categorizes tasks, completes (closes) them one by one. The task document itself is saved in a document versioning repository as the latest version.

• The task is marked for review. A peer, or superior – reviews the task, if necessary pulling the document from the repository. Final complete if Ok, else re-sends for re-work with comments.

• Spurious looking things are eliminated from the task list with an empowered click. All anomalies, results, activities, emitted by the task management system are peer or superior reviewed.

• Completion of a bunch of tasks is a trigger to update a project plan in say MS-Projects. Managers have the task of being on top of this task flow, allocating, re-prioritizing, and in extreme cases, doing a task themselves. Effectiveness is all about the graininess of the task, the resources supplied to the worker to do it.

• Project managers in particular have to understand the individual task completions against a backdrop of the complete project (a million tasks?) - and tighten the slack if exists.

• Meantime, all tasks having been completed, the worker plays some pool or some silent video game, or does some reading and “open contributing” over some forum. Or checks personal emails or does some on line shopping or vacation planning, all while sitting in the office.

• A meeting is called, so everyone opens the chat IM window.

• A meeting is called, so everyone calls a conference number in goToMeetings.

• A physical meeting is called, but the system shows all conference rooms are booked. So everyone including the CEO file to the pantry.

• Knowledge managers scour the universe for knowledge, keep the KB clean, and supply knowledge to the needy.

• Senior managers and top management only focus on key things – key accounts, key relationships, key deals, key events, key fire-fights.

• They are able to do this because they have progressively compressed dashboard charts and graphs. For example, the top testing manager knows only “3553 bugs today, target 3210 tomorrow”.

• External facing folks (sales people, vendor handling personnel) actually have cabins (!!) and even ancient looking telephones.

• No one fills time sheets because the basic unit of work is the “task”.

• Etc. etc.