ICS Management within post merger integration: analytical framework construction

Gomez & Habann (2001:p.365), Spikers (2002): First presented by Peter Gomez in 1998 (pp.62–65), in line with the St.Gallen management approach tradition (set by the St.Gallen management institute’s founder Hans Ulrich), which stresses the need for holistic / integrated thought in management theory and practice.Google Scholar

The model involves a successive consideration of: vision → rules → competence → strategy → process → organisation, maintaining the focus on value and the impact on value generatorsGoogle Scholar

St.Gallen Managemet Model — Ulrich & Krieg (1972), Schwaninger (2000:pp.391–437), Ruegg-Stürm (2002:pp.70–74)Google Scholar

This process, and hence the order of component examination / description begins with value (in the centre of the framework), to vision (normative level), and then clockwise until the cycle is completed (operative level)Google Scholar

Rieser (1999) for example, emphasises the importance of assessing merger value in terms of its impact on the all the elements of the organisation’s marketing mixGoogle Scholar

Habeck, Kröger, & Träm (2000:pp.20–30) argue that lack of a clear vision and a misplaced focus on “fit”, is one of the primary reasons for integration problems and subsequently merger failures. “Fit” does not constitute vision.Google Scholar

In Gomez & Habann (2001:p.368). In addition, Bereszewski, Kloss & Keβler (2002:pp.20–21) use the term “integration roadmap”, which lies between the generality of a vision and the specificity of a planGoogle Scholar

There are a number of frameworks seeking to align generic PMI visualisations with different combinations of strategic variables [see for example Haspeslagh & Jemison (1991: p.145) — ‘2x2 Degree of Integration’, Wall & Wall (2000:pp.119–141) — Integration Strategy Framework]Google Scholar

Clear and targeted communication is generally considered a preferred approach, as it minimises the risk of “attention deficit disorder” [Davenport & Beck (2000)] caused by a ‘bombardment’ of vague, general-purpose, PR messages within the organisation. A clear and concrete concept is easily understood and facilitates constructive feedback, which is also a characteristic of effective communicationGoogle Scholar

Bender, Ammann & Meitner (2000:p.28) state that concept acceptance is key for successful ICS management during a merger.Google Scholar

Born (2004:pp.31–32)Google Scholar

Within the context of ICS in post merger integration such trade-offs may include: resource allocation between ongoing operations and integration effort, acceptability of operational information risk and the degree of systems change necessary, etc. The listing of such trade-offs is avoided at this stage, since it should be situation-specificGoogle Scholar

Darragh & Cambell (2001) highlight the importance of clearly-set and communicated priority principles. For it is the lack of clarity that causes the failure of many corporate initiativesGoogle Scholar

Eisenhardt & Galunic (2000:p.98)Google Scholar

Theoretically speaking, cultures are also to a certain degree determined by market / industry characteristics / realities. Inasmuch as this assumption holds, the extent to which integration rules conflict with culture should be limitedGoogle Scholar

Broadbent & Weill (1996) use the term “maxims” instead of “game rules”, which derived from the company’s strategic context ought to guide investment decisions and determine the necessary capabilitiesGoogle Scholar

An almost identical listing of key elements, is also provided by Luftman & Brier (1999:pp.109–111)Google Scholar

Kiely (1996:p.11), Heygate & Spokes (1997), Bernotat & Scherdin (2002)Google Scholar

See for example Dvorak et.al (1997:p.170), Dempsey et. al (1997:p.85), James & Wolf (2000:p. 102), Abeltshauser & Rohr (2002)Google Scholar

See for example Morris & Ferguson (1993:pp.86–89)Google Scholar

Minz & Strobel (1997), Bereszewski, Kloss & Keβler (2002:p.23), Witte (2002)Google Scholar

EAI stands for Enterprise Application Integration (Generic term is “middleware”) and holds the promise of easing platform and system integration. EAI typically deals with the integration of applications and data sources within an enterprise [Linthicum (2000:p.16)]Google Scholar

Vinckier (1994). In addition, Sneed (2002) claims that developments such as the Extensible Markup Language (abbr.XML) is signaling the end of migration and reengineering. As a side note here, XML is central to middleware applications [see Linthicum (1999), Jechle (2001), Offermann (2002:p.24)]Google Scholar

Battles, Mark & Ryan 1996:p.125)Google Scholar

Fritisch (2001:p.37), Fritisch (2002:pp. 18–19), Vaske & Witte (2002), Gonsalves (2003): This is gradually reducing corporate preference for large-scale deployments of EAI technology (Yankee Group Market Research). Kanakamedala, King & Ramsdell (2003) heavily criticise the ability of XML (which lies in the heart of EAI) to revolutionise data exchange between applications and networks. Their criticism is conducted on the basis of high cost, low degree of standardisation (technical standards, business semantics)Google Scholar

Devaraj & Kohli (2002:p.114) distinguish between data, information, knowledge and ultimately wisdom, underlining the role of interpretation and common understanding. Similarly, Davenport (1994:p.10) characteristically states that “No Unit of Information is too basic to prevent disagreement about it’s meaning”Google Scholar

In terms of dealing with complex system landscapes, Dempsey et. al (1997:p.86) claim that, often, the real problem is not related to “legacy systems” but “legacy cultures” (i.e. strong separation between systems and business issues), reducing the effectiveness of an IT organization to a minimumGoogle Scholar

Markus & Benjamin (1997:pp.62–64) stress the need for IT facilitators / IT advocates, as specialised change management role. The urgency of newly establishing this as a separate role, depends of course on the present skills of the IT and business resources involved, as well as on the degree of complexity dictated by existing technological bases and their differencesGoogle Scholar

That means considering other “management instances” within PMI — E.g. HRM, organisational structureGoogle Scholar

Berensmann & Spang (1998:p.36)Google Scholar

A similar set of options in presented by Lehmann & Scheuse (2000:p. 16)Google Scholar

Bereszewski, Kloss & Keßler (2002:p.24) graphically name this approach: the “Highlander approach” (i.e. there can only be one!)Google Scholar

See also Kiely (1996:pp. 10–11)Google Scholar

A number of companies’ core systems, aside being developed a long time ago, may also have a long history of adaptations and expansions, while sharing interfaces with a number of other newer systems. Considering the rapid technological advances, programming skills and knowledge become quickly out of date and are hence difficult to acquire. Legacy systems, especially the ones developed during the early days of the information revolution are likely to lack documentation, rendering them ‘alien code’. In addition, a large number of interfaces and interrelationships between systems increase complexity and risk. Changes in one of the systems may cause a ‘chain reaction’ of unexpected catastrophic events for the entire landscapeGoogle Scholar

Meier & Spang (2000:pp. 10–11)Google Scholar

LaJoux(1998:pp.255–256)Google Scholar

Davenport (1998:pp.167–171)Google Scholar

Battles, Mark & Ryan (1996:pp. 122–125) claim that this is particularly the case today due to the shortening of business, product and technology cycles. The relatively long application development cycles under those conditions effectively means that it is very difficult for ICS to deliver business valueGoogle Scholar

For an overview of structured methods refer to: Ross, & Bracket (1976), DeMarco (1978), Yourdon & Constantine (1979), Yourdon (1989)Google Scholar

University of Albany Center for Technology in Government (1998)Google Scholar

Miller (1998:pp. 106–107): This represents a very popular and generic approach to systems development and there are various names attributed to it. Just to mention another variation, Schulz et. al (1996:pp.30–33) refer to a very similar generic software development model they name: “Top-Down Phase model”Google Scholar

Davis & Yen (1999:pp.03–10)Google Scholar

Extensive coverage of IS methodologies, their origins, development and shortcomings can be found in: Kumar & Welke (1992), Avgerou & Cornford (1993), Avison & Fitzgerald (1995:pp.08–36), Fitzgerald (2000:pp.13–15)Google Scholar

Beck (1999), Langley (2000)Google Scholar

Miller (1998:p.185)Google Scholar

Examples are: rapid application development (abbr. RAD), joint application development (abbr. JAD). For a short description of JAD refer to Davis & Yen (1999:pp.247–252) or Langer (2000:pp. 19–25). For a short description of RAD refer to Davis & Yen (1999:pp.97–103)Google Scholar

Cabral (2001), Dean & Dvorak ( 1995:pp.51–57)Google Scholar

Pietsch(1997:pp.23–24)Google Scholar

Jacobson, Booch & Rumbaugh (1999:p.89), Kruchten (2000:pp.06–07)Google Scholar

University of Albany Center for Technology in Government (1998), Davis & Yen (1999:pp.241–245)Google Scholar

Boehm(1988)Google Scholar

Turner (2001)Google Scholar

See for example: Avgerou & Cornford (1993), Avison & Fitzgerald (1995), Fitzgerald (1995). An interesting argument, with regard to the practical (mis)application of methodologies is provided by Fitzgerald (1996), who questions the very value of methodologies altogether on that basisGoogle Scholar

Reiss (1996:pp.08–48), Berensmann & Spang (1998:pp.40–41), Galpin & Herndon (2000:pp.69–92), Bender, Ammann & Meitner (2000:p.28)Google Scholar

Definition extracted from www.apm.org.uk/pub/glossary on the 16.07.2002Google Scholar

Lauritzen (2000:p.23)Google Scholar

Generally speaking, it is safe to assume that external human resources (i.e. consultants) tend to cost significantly more than internal ones. The risks associated with information and knowledge ‘leakage’ are also to be considered seriously in the sensitive environment surrounding a mergerGoogle Scholar

Over-formalising procedures implies loss of flexibility which can be detrimental for the success of a project (delays, frustration / tension, time-wasting, etc.). Hallowell (1999:pp.60–61) warns against the uncontrolled and exaggerated usage of technological tools (especially electronic communication tools). The ‘human moment’ (i.e. psychological encounter when two or more people share the same physical space) is indispensable; its absence having consequences such as: anxiety, over-sensitivity, self-doubt, alienation, and aggression. These can severely hinder any kind of project / programme effort within merger situation, especially during initiation when there is ample room for such feelings to flourishGoogle Scholar

With hindsight they might indeed be obvious. However, the pressures present during integration may often prevent the participants from seeing the obviousGoogle Scholar

The term ‘counter-measures’ is avoided here, because the focus is on dealing with the problem in its root and not just counter-acting. To illustrate the difference, an analogy from medicine might be useful. Taking an aspirin to deal with a headache is a counter-measure. Establishing that the headache(s) is due to de-hydration, and subsequently increasing water-intake is a corrective measureGoogle Scholar

Komus & Reiter (2000:pp.40–41), Wall & Wall (2000:pp.03–18)Google Scholar

Strassmann (2003) discusses the importance of post-consolidation evaluation placing emphasis on ICSGoogle Scholar

Martin, Lemp & Mautere (2003:p.73)Google Scholar

Malik (1999:p.252) argues for the necessity of explicit logic and principles within the context of mergersGoogle Scholar