Governments need to accept that technology and society evolve instead of trying to hold back progress at the behest of corporations?

A fun competition, an angry public – what could possibly go wrong?
Qantas via Twitter

By now, most people will have heard of the social media disaster which even provided its own hashtag: #QantasLuxury. Ironically, this was everything but a luxury for Qantas.

What it did illustrate was a marketing department that was totally out of touch with what the company was doing and what it really needs to do to overcome the PR disaster that was the grounding of the Qantas fleet on October 29.

So, how did the story unfold?

At 9:00am on the yesterday morning, the “social media team” at Qantas, as part of an ongoing “social media campaign”, released details of a competition on Twitter:

Twitter

They had run campaigns like this before. The prize? Well, as you can see from the photo at the top of this article, hardly something that would launch a Twitter frenzy of positive sentiment. The most notable part of the prize were the pyjamas …

What they got – instead of a few tweets of marketing fodder – was a deluge of sometimes caustic, but at best sarcastic, vitriol reflecting more on the ongoing labour relations battles with the unions and the grounding of the fleet than the quality of the service.

Another interesting observation is that once a Twitter trend starts, it is self-feeding: supporting tweets appear that are self-referential, about the trend itself.

Twitter

The negative commentary took an even bigger dive when a parody of Downfall – a film depicting the last days of Adolf Hitler – was posted on YouTube, as seen below.

The problem for Qantas was that the parody was very well written and pretty much summed up the sentiment of the public, and probably of CEO Alan Joyce himself.

An analysis of approximately 2000 tweets gives a graphic illustration of the way the Twitter trend maintained the sentiment over the course of the day.

wordle

Fortunately for Qantas, as the east coast of Australia went to bed the tweets died down. It will be interesting to see if this changes today (Wednesday) but the sentiment has been vented.

trendistic

On the positive side, Qantas has now received some fairly unambiguous market data about how the public feels (and it was free). It seems clear the Qantas “social media team” are astoundingly amateurish and probably reflects the low priority that Qantas puts on this.

A statement that Qantas had recently hired social media staff to monitor social media for sentiment about Qantas was denied on Twitter.

As Hitler says on the QantasLuxury Downfall parody: “With any luck someone will post a new funny cat video”, otherwise he will “ground the whole internet”.

This article was originally published at The Conversation.
Read the original article.

The traditional organisational chart views the organisation by functional areas such as marketing, accounting, production and so on and makes no reference to customers, products, services or work flows and yet these are essential parts of a business. This is the rational for developing a ‘systems and process’ model as an alternative way of looking at an enterprise. When looked at this way value chains can be identified and optimised.

This however raises issues between as Harmon puts it on page 71 the “lumpers” who want to “include everything that is even vaguely similar and arrive at one or very few values chains” and the “splitters” who can end up with many value chains. As he points out there is no right answer and consensus needs to be achieved from within the organisation.
Strategy

“A business strategy defines how a company will compete, what its goals will be, and what policies it will support to achieve these goals” (Harmon page 31).
Defining a strategy is important because this, in essence, becomes the reason for a business to exist. Harmon describes an approach advocated by Porter published in his book ‘Competitive Strategy’ in 1980 as essentially a three phase process of determining what the company is doing now, what is happening in the external environment and what the company should do next.

Porter illustrates generic strategies such as cost leadership, differentiation or niche specialization and the need to be able to construct or maintain a competitive advantage by using value chains related to strategic positioning rather than operational efficiency alone.  He warns of ‘hyper competition’ where companies are locked in a race to improve operational efficiency that in the long run cannot be sustained because competitors will also be able to achieve this.
A business needs to create a ‘value proposition’ and develop a strategy around this. Activities must be aligned, and if possible tightly integrated with the strategy position to not only to support the strategy but to also protect that position from competition.
Personal Reflection

The functional organisation of an enterprise is also critical to its success and therefore the challenge for many organisations is to align processes with functional areas.

For instance if the organisation is essentially on a common platform with a seamless integration of their IT infrastructure and associated  information systems   then to a large degree the criticism of various functional areas maintaining their own databases and creating communication and process ‘road blocks’ can be alleviated.

Functional areas contribute capacity to the enterprise in ways that do not always neatly fit the current ‘value chain’, particularly in a changing environment and so I am wary about taking a too narrow focus on ‘process’ over ‘function’.
I understand in certain situations, particularly in industries like mining and manufacturing optimising a value chain is crucial and a process driven model will be the best way to optimise a value chain.

On the other hand as an example many organisations were able to transition to Internet enabled applications at a significant competitive advantage by having functional areas developing and using Internet based technologies long before the enterprise was able to leverage, or even define these, as part of their value chain. They were able to enter new markets or take customers from competitors simply because they had developed a capability that at the time may have actually appeared disruptive to their existing value chain.

Porter introduced the idea of value chain to think of processes as complete entities from the customer purchase through to fulfilment (Harmon page 41) and so therefore perhaps this is not incongruous with the definition of a value chain and the important immediate concern is that functional areas remain integrated to the value chain and strategy of the organisation.

Nevertheless I have trouble with the concept that each activity in a value chain should (or must) add value to the final product. I was heartened to see on page 41 Harmon comment “It’s a little more complex of course ….. there are some activities or steps that don’t add value, directly, but facilitate adding value … there are some process’s that are “value enabling” activities ….”
In my experience there are also activities associated with government regulation or other compliance issues that would go into the category of ‘the cost of doing business’ rather than efficient process management.

He then went on to suggest that the reasons to focus on value however is to identify activities which don’t add value and have become, for one reason or another, not relevant to the process. I am much more comfortable with looking at value chains from this perspective.

Middleware was a means to an end but very inefficient because organisations were still supporting multiple disparate systems as well as the middleware itself. The next phase in the evolution information systems was the growth of ERP style systems such as SAP, a single integrated environment with common data structures, languages and reporting tools shared across the enterprise.

Hence vendors such as SAP and others moved beyond simply controlling the data itself but into managing and controlling the processes and work flows of an organisations entire value chain; this facilitated the evolution of workflow management systems where software can define create and manage workflow across the enterprise.

There was no need for middleware because ERP vendors transformed the previous generation of discrete monolithic ‘off the shelf’ applications for work areas such as accounting, inventory or human resources into a cohesive set of linked applications (modules) so data could be maintained across the enterprise in a seamless fashion (since they were all using the same database objects).

These systems not only manage work and process flows across an enterprise but in many cases facilitate best, albeit common practice for functional areas. This leads us to where we are now with enterprises typically supporting information systems that are accessible with industry standard communication protocols and data formats and providing the means of BPMS managing enterprise business processes.

Key Issues:

ERP systems are by no means a panacea as they are complex, expensive and require significant human and technical resources to maintain.

Many organisations customised their ERP applications and this not only adds further expensive but is time consuming and fraught with the  danger of introducing workflows that don’t integrate across the enterprise (the very thing you are trying to achieve). It also introduces considerable maintenance overheads coordinating these changes across new versions.  That is, as vendors release new ERP modules customisations need to be redone and often divisions become locked into old or multiple versions of ERP systems out of step with the rest of the enterprise.

BPMS are an alternative to this scenario. These suites are potentially more agile and productive, easier to develop and maintain and can focus on bridging the gap between process managers and software developers. There is a lower implementation and development risk as they can be layered over the top of ERP and other corporate data systems. They can be developed, tested and even replaced with alternative systems without disturbing the existing architecture.
The difference between middleware and BPMS is that these suites are usually integrated to a homogeneous environment rather than needing to connect disparate IT systems as was the case when middleware oriented solutions first appeared. This need not be the case of course but usually enterprises like to lower their cost of ownership by adopting standard operating environments (SOE).
The current generation of communications and data standards; based around Service Orientated Architectures (SOA) such as Web Services and XML (Extensible Mark-up Language) have created the opportunity for vendors in the BPMS market to add considerable value to the enterprise without requiring them to replace their existing investments.

As an example I have compared two such suites chosen from the BPTrends Report on  five of the criteria cited in the report. I have chosen to compare the Oracle BPEL Process Manager (version 10.1.2) and Adobe Live Cycle Workflow (Version 7).

I chose these two because Oracle is a major vendor of ERP systems and well placed to integrate their BPMS offerings and Adobe, although not a developer of ERP systems is one of the world’s largest and diversified software companies whose specialisation has been on the desktop.

I was interested to see if the  different backgrounds of these vendors would be reflected in their products. The first point of comparison is the BPM Engine.

The BPM engine is essentially a server providing the technical nervous system for the BPMS. It must manage communication and database connections, data and process flows, allocate and de-allocate resources and provide the executable environment for the various applications that use it.

The functions within a BPM engine generally require IT infrastructure; such as Microsoft .NET or J2EE the java platform supported by SUN Microsystems and others. Some vendors write their own languages (such as BPEL) and application servers rather than use the native support from major IT vendors. In for example standard web page servers such as Microsoft IIS or open source Apache are replaces by propriety applications servers providing similar functionality.

Not surprisingly both Adobe and Oracle support a Service Orientated Architecture that facilitates component based architecture. Therefore they both support Web Services and the full suite of standard communication protocols (eg HTTP, SMTP) and data formats (XML).

They also run on both J2EE (Java) and Microsoft .Net application servers/platforms. This is important because organisations will have an existing commitment to a development platform and
will not necessarily want to maintain two different environments.

However both of these products require J2EE application servers and so in a Microsoft Internet InformationService (IIS) environment it may require maintaining two technical skills sets
(both .NET and Java) in the enterprise. Of course the whole point of Web Services is to be a language agnostic, message based environment however typically organisation cannot avoid doing work in the native languages of a particular platform.
Integration of both products to existing IT infrastructure however is good since they both support the full set of Internet and SOA protocols and services (for example WSDL, email, XML, JDBC,
HTTP GET and POST)  and many other protocols enabling connectivity to back end systems and services.

Oracle uses their BPEL product as a development platform. Therefore if the organisation doesn’t already have a commitment to an Oracle based ERP solution (like PeopleSoft for example) there
will be significant start up costs in training and support to develop using this language.

Both Oracle and Adobe support Application Programming Interfaces (API) to their systems but only for Java and Web Services are required from other languages.

Both have graphical user interfaces for modelling and design and in the case of Adobe this has the distinct advantage of having the look and feel of familiar Adobe desktop
products. It also offers a library of templates and components for assembling and creating workflows without programming. On the other hand the Oracle, with its years of investment in languages and programming tools has taken the path of using the usual drag and drop graphical capability to produce fully operational BPEL code. Their BPEL Designer then is a far more capable product in terms of capability but again to get the most out of this an enterprise may need a significant investment in an Oracle ERP based system.  The Oracle product also includes wizards to model common process and work flows.

The scalability of both Oracle and Adobe are similar since they both provide for load balancing, clustering of servers and Light Weight Directory Access Protocol (LDAP) for user management. This is essentially achieved on both systems by using standard technology from major IT service providers rather than creating their own propriety architecture.

Similarly both use the XML based query language XPATH and SOA services for the creation, control and maintenance of business rules. Both have graphical tools to achieve this.

A cost comparison is not really possible because of the many variations than vendors use to determine their pricing so for this class of software it requires creating a request for proposal or similar and soliciting quotes. The 2007 article mentioned the cost of the Oracle BPEL Process manager at $40k per processor and the Adobe price is only available after requesting a consultation.

Personal Reflection

This class of software is difficult to select and as mentioned organisations would typically outline their requirements in a document and call for a request for a proposal (RFP).  In my experience alarm bells should start ringing when the only means to establish the cost is to go through this sort of process. Typically vendors will seek to charge on the basis of ‘what you can afford’ particularly for larger organisations. There are complex variations of charging models with named users, seats, client access licenses and so on making the comparison of costs between various systems difficult to ascertain.
The selection of a product on technical and operational issues is difficult enough but the sales process is often more challenging especially if there is the opportunity to split offerings into many modules and dependencies further complicating the purchase decision.  The sales division of vendors in this class of software are often focused on maximising the return for the vendor rather than simply selling a product as is the case with vendors that sell
more mainstream ‘off the shelf’ products.

Additional Reading

Harmon, Paul. Business Process Change (Chapter 15,16).
Khan, Rashid N (2006). BPM A Global View, BPTRENDS web site.

Mistake #1: Hiring Based on Price Alone

There’s a reason this is the first mistake. It’s committed more than all the other mistakes combined. People have a tendency to think that all developers are the same, so cost should be the major determinant in who they hire. It’s a big mistake, and unfortunately I’ve seen some people make this mistake more than once.

In reality, hiring the wrong company starts a viscious cycle. When you hire the wrong company you enevitably make other mistakes such as paying too much in advance, not having complete functional specifications or setting unrealistic milestones. And once you’ve paid out enough money you are caught between a rock and a hard place. Do you keep going to save the money you have already spent or cut your losses and walk away and start again? Either way it’s a waste of time and resources.

So can you avoid this? First, past performance is a good indication of future performace. Rate the companies you are considering based on factors other than cost alone. Check references, review similar projects and ensure your functional requirements are well defined. These are obvious items but here are some you may not have thought of:

• Ask them how you are going to monitor the progress of the project. Make sure they don’t just add this as a functional requirment and add it to the cost of the project!
• Ask them if they use Subversion (or any similar repository)? All reputable
  developers know what this is.
• Ask them about Continuous Integration, and which tool they use to manage their builds.
• Verify the exact coding standards they use when documenting your code.

These are not iron clad questions, but I have interviewed many developers over the years and I am shocked how many get all 4 of these wrong.

Mistake #2: Don’t Pay Too Much In Advance

If you committed mistake #1, I can just about guarantee you’ve committed this one too. Understand that I am not just talking about the initial retainer.
You don’t want to pay too much more than the work that has been done – just like building a house. If you do, the developer is stuck with a lot of work and no future revenue to offset this cost. But what about the money you already paid them? It’s gone. It was used to finish another project before yours that also turned into a disaster.

Structure your payment schedule around deliverables, or milestones. Basically bill for the next part of the project on completion of the
current part. Bill based on results. Keep in mind that it is critical that you understand how much of the project will be complete, and then make sure the
payments you make roughly represent the percentage of the project complete to that point. Why do you think costs for projects balloon out by massive amounts- people just keep paying having no idea at what stage the project is at.

Mistake #3: Not Getting a Non Disclosure Agreement

How do you feel about the software you’ve paid to develop being shipped out the back door as a product of the developer? Suddenly they are experts in something you have designed and it’s a product they now sell to your competitors. If you have a good idea, and your product becomes a huge success, the last thing you want to do is find yourself in a dispute with your developer. It is critical that you have the company you hire sign a Non Disclosure Agreement which also assigns all rights to the software project to you. In fact, you should have this NDA in hand before you even start discussing your project with any company. We give one to every prospective client.

#4: Not Owning the Source Code

You are hiring a company to write a lot of code. This code represents the product you are buying. You need to make sure that the agreement you
sign grants you sole ownership of this code. Otherwise you’ve just paid your competitor to steal your idea. You need to own the code not the developer who in the absense of an agreement to the contrary will own it. If you don’t own the code you have no rights to it including developing it further with another developer. You need to own it. Period. Get this in writing.

#5: Undocumented Source Code

This has to be one of the most common mistakes. Imagine this. You pay a company to write thousands of lines of code. When they are done the
program works fine. You call the company back to get some changes done, only to find out the company no longer exists. Fortunately you recevied the source code
from them previously, so you confidently search for someone else to continue development. And then you get the bad news. The source code has absolutely no
comments or explanations describing why the code was written the way it was. This is a huge issue in our industry. In 9 out of 10 cases, the new developer is
going to tell you it is easier to start over. And in many cases, that would probably be good advice.

We have a simple way to avoid this issue. We perform code reviews on a regular basis to verify that our coding standards (which include commenting
source code) are being followed by all members of our team. Our internal audits are designed to make sure this situation does not happen.

#6: Not Asking for Documentation

You are paying good money for your software project. You owe it to yourself  to get all the documentation the software company created during the life of
your project. Why is this important? Imagine for a minute that the company you hired goes out of business a year or two down the road. What do you think the
chances are of ever getting documentation? We provide our clients with functional specifications, business requirements, test cases, data dictionaries,
and a host of other project artifacts. God forbid something happens to us. At least you have a good chance of finding another company to help you support and
enhance your product. It is often as important to know why something was done in a particular way as to how.

#7: Not Doing External Audits

If you really want to cover yourself, you should hire another company to  review the code your developer is building. This has several benefits. First, there’s nothing like an external audit to make sure your programmers have double checked and fixed their sloppy code. The company you hire to do the audit also
wants to give you value, so they are more than likely going to find some issues. This doesn’t mean your programmers are bad. Everyone misses something every once
in a while. But by letting the company you hire know from day one that an external audit will occur at some point, you are already putting everyone on
notice. We’ve been on both ends of this, and the client always came out the winner for it.

So there you have it. Seven mistakes you can avoid if you want your  software project to have a good chance of success. Good luck!

Don’t pay ridiculous prices for search engine optimisation when it should be part of good web design!

For example does your site have:

• A robots.txt file.
• A sitemap.xml file.
• Google Analytics account with Verification (MOST IMPORTANT!).
• Full Search Engine Optimisation of all your important pages.
• A Search-Engine-Friendly ‘landing page’ for your primary keyword phrase (do you know how Google creates a quality score? We do).
• A keyword-rich ‘link in’ client directory.
• Inbound links to your site from high ranking quality websites.
• Submissions to quality directories.
• Links on the most important social media services.
• On-demand traffic, page analysis and keyword reports to measure your progress.