Keywords

1 Introduction

Enterprise Modeling (EM) has proved to be a practicable approach that supports congruent organization and information system (IS) development by creating an integrated and commonly shared model describing different aspects of an enterprise (e.g. goals, business process, concepts, rules, etc.) More about the applicability of EM is available in [1].

In Scandinavia, Business or Enterprise Modeling were initially developed in the eighties by Plandata, Sweden [2], and later refined by the Swedish Institute for System Development (SISU). A significant innovation in this strand of EM was the notion of business goals as part of an enterprise model, enriching traditional model component types such as entities, and business processes. The SISU framework was further developed in the ESPRIT projects F3 – “From Fuzzy to Formal” and ELEKTRA – “Electrical Enterprise Knowledge for Transforming Applications” leading to an EM method called EKD – “Enterprise Knowledge Development” [3, 4]. It was used in practice for more than a decade of application in practice and continuously improved, primarily in terms of method guidance, to become the 4EM – “For Enterprise Modeling” method [5]. F3, EKD, and 4EM were mostly developed by researchers in the EU and nationally funded research projects. In parallel to these developments a number of successful consultancy businesses spun off the initial SISU EM community the experiences of which are summarized in [6]. Elsewhere in Scandinavia EM approaches have been developed in close integration with modeling tools, with Troux Architect (initially developed under the name of Metis) and Active Knowledge Modeling (AKM) being a notable example [7]. Apart from the “Scandinavian strand” of EM, a variety of other EM methods have been suggested (c.f., for instance, [8–13]).

Many EM approaches have been developed together with industry partners and successfully applied in a significant number of industrial cases. In the case of EKD and 4EM, since 2000, it has been applied to ca 40 organizations, but most of these applications have been involving the developers of the method. Similarly, i* [13] is a popular approach for goal and requirements modeling and is widely used in the scientific community, yet its industrial use beyond the research community is, to the best of our knowledge, insufficient. Some methods have been developed together with tools (e.g. AKM), for some (e.g. EKD and 4EM) several tool support solutions have been developed, and some EM approaches have adopted the strategy of using simple drawing tools (e.g. Visio) for model documentation (c.f. [6]). In summary, the current state of EM method and tool adoption is such that many potentially useful methods and tools are not used beyond the broader community (industrial and academic partners) that developed them. A possible cause could be the fact that EM methods and tools emerge from R&D projects with little or no focus on how to launch a finished product in the market. Hence, the current situation is that EM methods and tools are not generally intended and developed as commercialized products initially. i.e., they are not developed and managed as products, and we can conclude that the concept of productization within the area of EM is not addressed consciously. This may be due to the fact that the productization processes are fairly generic and do not consider the specifics of this product category. To this this end, the research question addressed in this paper is as follows: what factors influence the successful productization of enterprise modeling methods and tools?

This study focuses solely on success factors of EM methods and tools from a perspective of their development and management as products. I.e. we are not analyzing the theoretical and technological construction of EM methods and tools as design artifacts. Other methods or tools, e.g. for supporting business process management, IS analysis and design, and model-driven development are considered out of scope of this study.

The rest of the paper is organized as follows. Section 2 briefly describes the principles of EM, product development, and productization. Section 3 describes the research approach. Section 4 presents the research findings. Section 5 provides concluding remarks and issues of future work.

2 Theoretical Foundations and Related Work

This section briefly introduces the topics related to the research question, namely, EM, new product development, and productization.

2.1 Enterprise Modeling

An EM method consists of (1) a modeling language, (2) intended modeling process - including ways of working, EM project management and competency management - by which the enterprise models are produced. It also proposes (3) tools to be used during that process.

An EM language typically consists of sub-models each addressing a specific aspect of an enterprise, such as business goals, process, concepts, actors, rules, IS requirements. The components of the sub-models are related between them within a sub-model (intra-model relationships), as well as with components of other sub-models (inter-model relationships) see Fig. 1. The ability to trace decisions, components, and other aspects throughout the enterprise is dependent on the use and understanding of these relationships.

Fig. 1.
figure 1

Working with inter-model links (dashed arrows) through driving questions

Full size image

To achieve high quality results, the EM process is as equally important as the EM language used. There are two levels of the EM process – the EM project level and the modeling level.

The EM project level, where the modeling activities, such as, defining the scope of the project, planning the modeling activities, conducting modeling seminars, are placed in a context of purpose. The modeling level is where the domain knowledge is elicited, and enterprise models created and refined. When it comes to eliciting domain knowledge to be included in enterprise models, the Scandinavian strand of EM recommends a participatory way of working – facilitated stakeholder group sessions. The modeling process is consensus-driven in the sense that stakeholders collaboratively create and “own” the models, as well as govern their contents. In contrast, consultative participation means that analysts create models and stakeholders are then consulted to validate the models; cf. [5] for more on the EM process.

The EM process needs to be supported by tools. The tool requirements depend on the organization’s intentions (e.g. will the models be kept “alive”) and situational factors (e.g. the presence of skillful tool operators and resources). There are several categories of tools that can be considered such as group meeting facilitation tools, model documentation tools, as well as project communication and collaboration tools. More on the kinds of tools needed as well as on how to select and introduce EM tools in organizations is available in [5, 14].

2.2 New Product Development

New Product Development (NPD) process involves a sequence of activities such as an initial idea generation, evaluation of the idea as well as subsequent development, test, and ultimately market launch [15]. This process varies in different industries, thus it must be adapted to meet the requirements of a specific industry in order to attain the best possible outcome [16]. We follow the NPD framework [15] because it is one of the most widely recognized within the NPD field and it incorporates all the main stages that are required when developing new products. The framework categorizes the NPD process into seven consecutive stages, namely, new product strategy development, idea generation, screening and evaluation, business analysis, development, testing, and commercialization.

Considering the nature of EM tools and methods, the sequential distinction of stages in [15] may not be applicable since development of methods and tools is typically iterative and incremental. This regards especially the development and testing stages as they are usually intertwined. Although being separate tasks, it is common to develop method or tool prototypes, to test and adapt them repetitively rather than developing a fully functional product at once. Thus, this study conforms to the stages in [15] as being concurrent rather than consecutive.

Several authors within the field of NPD analyze various success factors when developing new products. For instance, Lester [17] identifies the following critical success factors for NPD, namely, senior management commitment, organizational structure and processes, developing attractive new product concepts, forming a venture team, and project management. Brown and Eisenhardt [18] argue that cross-functional teams, managerial skills, and support from senior management are crucial success factors. They extend [17] by considering additional factors that are linked to the market, financial performance, and product concept effectiveness.

Bhuiyan [16] connects the critical success factors to each stage of the NPD process proposed in [15] and proposes relevant metrics to measure the achievement of those factors together with tools and techniques for applying the metrics for each stage of the NPD process (see Table 1). This is also relevant to products in the area of EM.

Table 1. Framework for successful NPD [16].
Full size table

Good product ideas, functioning prototypes, and well-executed NPD projects are not sufficient for the success of a product. Maintenance of the new product in terms of planning, building marketing, distribution, and evolution are equally important. Hence, Software Product Management (SPM) covering both, the business and technological aspects of the product, is needed; cf., for instance [19].

2.3 Productization

Productization is a relatively novel area related to SPM and it is yet to attract a large amount of research. According to [20] “productization means standardization of the elements in the offering.” The term incorporates various technological attributes from inceptive stages of designing a product such as requirements engineering, creation of product architecture and selection of platform, to the commercial features regarding positioning, sales and distribution activities such as delivery channels, positioning and after sales activities. According to [20] the term productization is mostly used within the context of service and software industries with the aim of modifying intangible services into more defined product-like outcomes, i.e. creating defined offerings. The concept is applicable for the creation products and services in the area of EM.

Artz et al. [21] introduce a productization process for moving from developing customer specific solutions to product software. The process consists of the following six stages – (1) independent projects, (2) reuse across projects, (3) product recognition, (4) product platform, (5) standardized product platform, (6a) customizable software product, and (6b) standard product.

According to [22], the productization level increases as the maturity of an offering increases (see Fig. 2). The higher the level of maturity, the lower the abstraction level, which subsequently facilitates interaction with customers. Considering the current state of EM methods and tools, many seem to be at the lowest level, i.e. the methods and tools are developed but only used in practice by the extended group of developers and offered to a broader audience in an ad hoc manner. Several methods and tools are on the second level – the offering is well elaborated along with a clear-cut strategy of how to use it. But in most cases this is done from a technological point of view and essential business aspects for making a commercial success are missing. The latter is needed to reach the highest level of productization.

Fig. 2.
figure 2

Productization levels in context of service and technology (adapted from [22])

Full size image

The framework of [22] stresses the importance of inbound and outbound productization. Inbound productization includes the tasks for harmonizing and systematizing the offering’s delivery process. In the case of EM these are the processes of developing an EM method (e.g. by means of method-engineering [23]) or developing an EM tool as software. Outbound productization refers to the ability to sell, e.g. it aims at improving the visibility, compactness, and the perceived value of a product by customers. It should include brand design, licensing, training, and after-sales service. Most of the current efforts in EM are focused on inbound productization while tasks for outbound productization are considerably more neglected.

3 Research Approach

This study seeks to identify the factors that influence successful productization in the area of EM. Currently there is very little theoretical knowledge regarding this topic. Yet we have some hypothetical areas of investigation, e.g. that EM development projects are lacking inclusion of the concepts such as NPD, SPM, and productization. Furthermore, it is not always the case that methods and tools are developed as one product – an EM method can be supported by different tools and vice versa. Due to the lack of research, these assumptions are mostly based on our own experiences and observations in the field, as well as on communications with our peers. I.e. much of relevant empirical knowledge exists in “people’s heads” – experts and practitioners in EM. By virtue of this, it was suitable to generate the theoretical findings by conforming to a qualitative approach. The primary reason for this was due to the exploratory characteristics of this research. It was also important that the participants shared their inner thoughts and beliefs regarding the topic and henceforth a qualitative approach was appropriate. The research strategy chosen for this study is Grounded Theory [24]. The purpose of Grounded Theory is to generate theories from data via a continual process of contrasting the ideas with existing data, and ameliorating the emerging concepts and theory by scrutinizing them against new data gathered particularly for the purpose.

The method of data collection for this approach was unstructured interviews. The following categories of EM professionals were interviewed – EM and business consultants, researchers developing EM methods, as well as a product marketing manager. Interviewees were selected based on authors’ knowledge about their involvement in EM method and tool development and application in practice. Interviewee profiles are presented in Table 2. The interviews were transcribed and analyzed by the Altas.ti tool according to the principles of Grounded Theory, which included open, axial, and selective coding.

Table 2. Interview profiles
Full size table

Every interviewee agreed to participate freely in this study. They were fully informed of the research objective and the meaning of their involvement.

4 Factors Influencing Productization

This section presents the empirical findings in terms of factors influencing the success of productization, namely, EM maturity gap, method and tool development process, application context, marketing and sales aspects, as well as product aspects.

4.1 Reduction of EM Maturity Gap

The empirical data indicates a gap between research and practice views on EM in terms of what is important, as the following citation shows.

Citation 1: “I would say that we have different degrees of maturity in research and in practice. In research you get to a high level of maturity conceptual wise, you [in research] create theories and you make it very sound. It will work in a theoretical environment in an experiment environment, it will work, it is elegant. But the real world does not have those premises; you have different premises there. You have different situations where it’s stickier, it’s muddier, it’s more convoluted, it’s a different set of problems. It’s those wicked problems, if you like, dirty problems, they are not clean like you can do it in research.” [i4]

What the maturity gap in this case refers to is the actual belief of what characteristics a successful EM method or tool should encompass. The empirical findings show that there are different views towards this in research and in practice. As a result, methods and tools originating from research often oversimplify problems faced in practice. Practitioners’ view is that they are well designed and based on the existing research, but the fact that they are designed from a theoretical perspective leads to problems of using them in practice, as one interviewee states it below.

Citation 2: “The very good example for that, is the i* method…it is very difficult to get that out into practice…yeah, there are some very nice relationships, and some very nice things but very soon the models start to turn into something big, you can’t really read them and there are no good tools to work with and… Not very practical…so, the practical aspect…is the method practical? Does it help me to solve my problems?” [i2]

The different views of EM in practice and research also manifest themselves in the way people speak about EM. One of the interviewees [i5] said that in the industry people mostly talk about Enterprise Architecture, rather than EM, and that EM is merely viewed as one component of the whole enterprise architecture.

Moreover, many interviewees who were working with EM in practice claimed that using something that has not been “proven in combat” has a risk involved, since it may have a misconception of the complexity of the problems in the real world, as interviewee 4 points out.

Citation 3: “And the first question you will meet when you try to introduce a tool or a method to someone, let’s say a practitioner, is: has this been proven? Has this been used? Do you have any reference cases? Or can you show me something that actually works? Otherwise I am taking a risk if I am going to use this thing” [i4]

Many interviewees also pointed out that individuals from research and practice are not working together sufficiently enough to establish a shared view of EM methods and tools. Although there are various projects, usually financed as research grants that include individuals from both sides of the field, there is a lack of incentives to drive things further (in business terms) once the project is completed. From a research perspective the majority of the participants concluded that many researchers are not necessarily interested in pursuing things to the point of commercialization. Interviewees 1 and 2 point out the following:

Citation 4: “Very often the method developers have the interest of developing methods and not necessarily being consultants and selling…of course, we are researchers, so maybe we [personally] are not very interested in developing it into the market.” [i1]

Citation 5: “Well, because you publish a paper and then it is over. You will have another career. So, I think that the driving force behind these research - based methods is not the market, it is the research.” [i2]

Another factor leading to the low adoption rate of EM is related to EM projects usually being run from an IT perspective and not from a business perspective. The projects are mostly conducted from an IT point-of-view, but IT people do not have the mandate to successfully work with the business aspects. Thus, the lacking incorporation of a business perspective, such as the inclusion people with extensive knowledge on how to manage the company, business processes, and strategic goals, negatively influences on the overall success of an EM method or tool.

Citation 7: “… the biggest problem is that it is usually run by IT departments and they focus on technology, on methods, on tools, that’s not something most business are interested in. They are interested in the business. So for the few companies I know that actually manage to do this, what they all have in common is the fact that these efforts are run by business departments not the IT department. So I would say, it’s sort of a managerial issue. They do not have the right teams or the right organization. They are simply not doing it right.” [i5]

From a user perspective the EM method and tool maturity gap is affected by the existing competences and skills. Interviewees pointed to a high learning curve of how to apply the methodology or tools. The functionality of tools is often unexploited and they are simply used as drawing tools. Interviewees 3 and 4 described this in the following terms.

Citation 8: “We do not really have process owners that know what it means to be a process owner, so let alone, if we have this tool that we have documents and processes in, they do not know what to do with that. We have people who are skilled in using the tool itself but we’re just using it as a drawing tool. We do not use the repository capabilities and all that stuff. Because we’re not on that maturity level at all. And that goes for a lot of companies” [i4]

Citation 9: “One of the biggest barriers is (1) lack of education, and (2) freeing the most knowledgeable people in companies from their daily project work, working with paper flows and so on.” [i3]

In summary, the EM maturity gap should be reduced by the following – (a) Individuals from research and practice working together, and (b) modeling the IT and a business perspective in congruence.

In [14] we have defined EM method and tool usage maturity as determinant of how experienced and prepared the organization is to work with EM methods and tools. A key aspect of this is competence and if the organization wants using EM without external consultants it needs a “modeling department”; for more on this c.f. [1, 5].

4.2 EM Method and Tool Development Process

There is no commonly recognized process for developing EM methods and tools. One of the potential reasons for this is the difference of views of EM in research and practice discussed previously. A common perception is that methods should evolve based on previous experiences and include well-known approaches in a manner that is easy to comprehend and grasp. I.e., method developers should extract key things from different cases, find a solution, and develop a way of structuring it to make it comprehensible and appealing. Interviewee 4 compared a possible future recognized development process for EM with the business model canvas.

Citation 10: “Now what I have seen lately, that is very interesting is that the business model canvas…. Well, that model has been very, very popular; everybody is doing canvas – “oooh canvas”, like it was something new. There is nothing new in it; it is the same questions that have been asked all the time. It is just a different way of exposing it, and structuring it becomes graphical. And that is one thing that I’ve seen successful, a good example where ways of structuring problems becomes very popular because it does not only address the analytical part of your brain but also the structural with, for example, pictures. So, you have this business model canvas and you have those icons and pictures, and you have things like that, which makes it popular because it is just not bullet points on a PowerPoint. So it’s more attractive to view, it becomes a way of structuring it. So, one way of developing that will work very well is, if you can find ways of presenting already known facts but in a way that is easier to understand and grasp; then I think you’re on to something.” [i4]

Moreover, interviewee 3 identified four crucial success factors that must be taken into account when developing an EM method and tool as stated in the citation below.

Citation 12: “1: which sector you’re looking at, 2: the business situation, 3: the customer situation, and 4: the technological situation in the market.” [i3]

Another important aspect when developing an EM method or tool is making the right decisions not only regarding the actual method or tool that is being developed but also about how the project organization is set up by ensuring that the right people with the necessary competence are involved, and that they are given defined roles. Ultimately, it is important that the development of an EM method or tool follows the same type of process as any product being developed. The primary reason for this is that EM methods and tools are used by people and hence user acceptance must be ensured. Interviewee 4 stated the following.

Citation 13: “So, if you want to produce a method, a tool or something like that for management consulting, for instance, you must follow through the same type of process as you do with any product. Here in management consulting you do not want it necessarily in a computer, the tool here has to be able to work with people. So, if people can grasp it easily, then you can run with it.” [i4]

In summary, there is no commonly recognized process for the development of an EM method or tool as a product. What is commonly known and used are method engineering approaches to method development and software engineering approaches to tool development, but these merely see methods and tools as design artifacts instead of products. Hence, a successful inbound productization should have the following criteria: (a) the process of creating a core product (method/tool) must be systematic which contributes to the product being comprehensible and appealing to the users; and (b) should follow the same NPD process as any product.

4.3 Application Context of EM Methods and Tools

The success of an EM method or tool is highly influenced by the extent to which contextual factors are considered. Every interviewee stated that neglecting the application environment for an EM method or tool leads to failure. The context often contains many aspects that influence the problem that a method or a tool is designed to solve, which may only be discovered by using it in its intended setting. It is therefore crucial to understand the situation where the method or tool is to be used, which in turn requires presence in that specific context as there might be other aspects affecting the situation, as interviewee 4 exemplifies below.

Citation 13: “You might have to design the tool that solves the particular problem but the situation where this problem occurs contains a lot of other things that influence the problem that you haven’t taken into account.” [i4]

Considering the context increases awareness of the problem that is being addressed and allows designing a method or tool that can solve that specific problem. Awareness also allows for communicating with the stakeholders in a manner that is comprehensible for them, which, in turn, enhances success of the method or tool.

The influencing aspects are not always identifiable prior to setting an EM method or tool in its context. Hence, it is vital that methods and tools are extendable. Without such an option of agile extensions the likelihood of good results is small, as interviewee 3 states it below.

Citation 16: “We must have capabilities to adapt and extend them. Because they change during the lifecycle. You need an agile approach, model-based, architecture driven workplaces and that the evolution of them is stored in the architecture itself. The tool I am talking about is a multidimensional platform where all dimensions are agile approaches, adaptive methods (potentially throughout the whole life-cycle), adaptive tools and holistic design. Because the way we are handling properties and parameters in ICT today is completely wrong.” [i3]

In summary, the factor influencing productization regarding the application context is the need for an EM method or tool to be extendable in an agile way.

4.4 Integration of EM Methods and Tools

All interviewees agreed that neglecting integration is one of the key causes for poor practical performance of EM methods or tools. Integration is vital since an EM method and tool aims to elucidate and describe the different aspects of an enterprise through the creation of a shared model. As citation 17 shows, supporting integration is crucial since it affects numerous components that relates to the problem matter.

Citation 17: “I am responsible for an area and all these products that are related to that area. So, I’ve been responsible for Big Data and Analytics, so, in there I am supposed to brand that category. But I also have products in that category that support each other. I mean you can’t just say Big Data. You need a database, you need some analyzing tools, and somewhere to store it, and you need to handle it and so on… So, there are so many components.” [i7]

Integration is needed for the creation and management of products in general. Consequently, a lack of integration with the business results in difficulties in viewing EM methods or tools as products.

Another factor leading to difficulties in regarding EM methods or tools as products is the separation of a method and tool. Integration of them as package is preferred. Without it the parts will not be perceived as products, as interviewee 2 states it below.

Citation 19: “… if you just have a method then it is difficult to present it as a product of anything more than just of “this is my consulting service and we’re using this method”. If you have a tool then you have a stronger selling point because you can give something to the customer and there is something to license and something to support. So, a method plus tool always puts one in a stronger position than just having a method.” [i2]

On the contrary, some interviewees argued that we do not always have to develop a supporting tool whenever creating a new EM method because many methods can be used with existing tools. Moreover, it is less complex to develop a method than a tool because tool development requires software development. Interviewee 6 stated the relevant business concerns in this respect.

Citation 21: “You have to be aware of that there is a tool that can be used, and there are many tools around, so we do not have to develop our own. And it takes a lot of effort to develop a tool, so the market for a tool that is developed cannot be as small as our method it’s used only in certain places.” [i6]

The interviewees also stated that integration with other development activities within an organization is crucial for the usefulness of EM, e.g. see below. An aspect of this is being able to technically integrate with other methods and tools.

Citation 22: “The integration between EM and other development activities, like software development, business development, particularly the software development…if you can’t translate those models into what’s normally used for software development then the models are not useful. So, the integration with that kind of development and tools and development situations I think is an extremely important factor to think about.” [i2]

In summary, successful productization is influenced by integration – an EM method or tool must be able to integrate with business and other organizational activities.

4.5 Marketing and Sales Aspects of EM Methods and Tools

An EM method or tool must provide value to be successful. The interviewees argued that without value to be gained from using the method or tool it will be difficult to attract users. Interviewee 7 exemplified value creation by stating the following.

Citation 26: “You kind of need to show the value for them. Like, what is the business value? How are the results going to improve by buying this tool? How are you being optimized? How is it going to affect your day?” [i7]

The interview analysis show that the value is affected by what can be called soft attributes, such as, positive psychological qualities experienced from a product such as, e.g., appreciation, positive user experience, emotional satisfaction, and fulfillment.

Citation 27: “…you need to add the soft values, that’s what’s gonna sell a product, because the product won’t sell itself and you can’t rely on product features and functions to be cool. That only works depending on what kind of brand image you already have…” [i7]

Citation 29: “…more and more we need to think about the psychology of it… Humans are humans and we are gonna interact in a certain ways and react in a certain ways. And we like to feel different things so if you manage to push on those things and also have a product that is complementing them then I think you have a success.” [i7]

One must therefore sell the usage of EM in a manner that focuses on the desired effect, by understanding customers’ business and how the use of EM would improve it. Hence, interaction with customers is needed. Yet, the interviews show that in reality there is little focus on customers. This is especially the case when an EM method or tool has been developed by researchers. Interviewee 1 stated as follows.

Citation 30: “The strategy is always “we want this cool tool” and there is somebody that wants it; there is usually a project in which you use it for a specific business problem in some company, that needs to be solved. This is how all these ‘A’, ‘B’, and ‘C’ projects started…. But this is not your customer; it’s your partner. So, there is no notion of customer. There is a notion of a business partner, who can later become a customer but seldom does.” [i1]

One of the causes for the lack of clear focus on customers may stem from the fact that consultants are seen as the primary users for EM methods and tools. A belief is that consultants easily grasp how a method or tool is to be used due to their expertise and hence no focus is put on how to address them from a marketing and sales perspective. This mindset is inadequate and the interviewees agreed that it is vital to involve the customers and interact with them on the basis of their needs and preferences. i.e. customer centric marketing and sales processes should be established. It is influenced by how one builds a story, which allows customers to envision how a specific method or tool will satisfy an existing need in a better way than what is currently used or being offered by the competitors.

In summary, productization should include attributes related to an extended product that delivers customer value and complimentary assets. EM marketing and sales must be carefully thought through as well as value must be provided including soft attributes. These are the factors that include the characteristics needed to constitute an extended product. This leads to achieving outbound productization, i.e. the ability to sell. From an EM marketing and sales perspective the following is needed – (a) an EM method or tool must provide value to customers, and (b) it should address real business problems.

4.6 EM Methods and Tools as Products

The empirical results show that there are various factors influencing the view of an EM method or a tool as a product. One of the key findings is that it must consist of a full package. Thus, in addition to the actual EM method or tool itself, all activities and tasks that are related to it must cover the integration aspects (see Sect. 4.4). This regards everything from the language used in the method or tool to the training and introduction of EM in the company. Interviewee 2 described it as follows.

Citation 35: “… if it is supposed to be a product, it should be the full package. It should be a language, it should have guidance for the process when you model how to do that, there should be a tool, and there should be a good link to other methodologies. So, there should be a good integration with it, there should be very clear, which roles are involved in using the methods. There should be some idea of how to train people to use these methods. If you have all these things, I am sure there are more things that could be added, then I think you have a product. You have an EM product that should be marketed. But coming just with a language or just with a tool is not going to work.” [i2]

Thus, it is of high importance that a product is extendable so that it can adapt to the changing needs of the environment as discussed in Sect. 4.3. Yet, our investigation also uncovered that customers and consultants do not generally perceive EM methods and tools as products. The three main causes for this is the lack of management, the lack of consideration of soft attributes (see Sect. 4.5), and the fact that an EM product is usually regarded as what is being produced by using the tool or method (models) and not the actual method or tool itself, as the citation below shows.

Citation 38: “The problem with EM is that… the product isn’t the EM, it is not really…the product isn’t the EM, the product is the models you produce with the EM. That’s the only thing the customer is interested in. It’s like trying to sell someone a hammer when they’re really interested in getting a house. They want the house; they do not care how the house is built. So, they are products but it is hard to get customers to view them as products.” [i4]

In regard to management, many participants said that emphasis is rarely laid on it in terms of product management, as interviewees 2 and 4 exemplified below.

Citation 36: “I would say that there is no focus on managing this as a product.” [i2]

Citation 37: “It is very rare actually that you have someone who is responsible for the tools and methods and that stuff, it is very rare. It is not very common because people in organizations focus on the business not on improving the business, and this is a problem.” [i4]

Some interviewees suggested that using some sort of standardization could make the perception of EM method and tools as products more complete. This suggestion follows the common principle of IT product alignment and integration with standards. Interviewee 1 compared it to OMG below.

Citation 38: “… in system analysis or system design there is UML. For business process there is BPMN. These are OMG standards. So, this is another angle where modeling methods should work, is towards standardization. Because similarly to BPMN there are standards and there are tools supporting it. For EM there is none, although there are some attempts; there is the business motivation model that is also part of OMG…. But there are no integrated sets. So, promoting EM through standardization and professional bodies is one way.” [i1]

On a somewhat contrary note, the participants stressed the importance of not trying to make something general initially and to focus on specific domain or problem area, as interviewee 5 stated.

Citation 39: “…never try building a general solution that can solve any problem. Instead try focusing on specific problems that you’ve actually observed if it’s in the organization or amongst your customers or whatever your domain is. And solve those first. Once that is done then you can look for how to extend this, How to make it more general. But never try to be general from the beginning because then you will end up with a monster like [method X] or one of these really, really big frameworks that don’t work in reality.” [i5]

It can therefore be concluded that factors contributing to a successful EM method or tool are (a) a complete method and tool package, (b) alignment with standards, and (c) focus of a specific market.

5 Conclusions and Future Work

We have analyzed what factors influence productization of EM methods and tools. The primary focus has been on developing products rather than just method and tool artifacts. Hence, we have primarily focused on NPD and aspects of outbound productization. Figure 3 shows an overview of how the different factors discussed in Sect. 4 are related to productization; the links are used to show positive influence. Due to lack of space we have not analyzed dependencies among the factors.

Fig. 3.
figure 3

Overview of factors influencing EM productization.

Full size image

We have concentrated on the Scandinavian strand of EM but in principle our findings seem relevant to other EM methods and tools as well although more analysis of productization of other methods and tools is needed. This investigation should merely be seen in an initial attempt to identify the potential areas to which the EM community should pay closer attention. More in depth analysis of the existing findings is needed. Among the issues for future work we envision the need to develop NPD and productization approaches that are specific to EM and based on the best practices that exist in the field, to further investigate the process of method and tool acquisition and adoption in organizations, as well as to support the integration of EM with other areas of organizational development and management beyond what is traditionally seen as topics of Computer Science and Information Systems.