Tải bản đầy đủ - 0 (trang)
6 Knowledge of Business Processes, Business Models, and Partnerships

6 Knowledge of Business Processes, Business Models, and Partnerships

Tải bản đầy đủ - 0trang

23.6



Knowledge of Business Processes, Business Models, and Partnerships



291



than developing the missing competencies from the ground up. If they provide

support for central aspects and understand the business domain, the question arises

whether they should not merely act as suppliers but as true partners—partners who

participate in the potential business success but then also bear part of the risk. Of

course this is no panacea. Maintaining sole control of a new business model is often

more important than sharing the risks and opportunities. Sometimes, new business

models are also used for practice. Many suppliers are not eligible as partners. But in

the time of the New School of IT with its focus on new business models and the

convergence of systems of records with systems of engagement, involving partners

(formerly called suppliers) more closely should at least be considered. Possibly

some business models are easier to establish when all competencies are exploited so

they focus solely on the success of the business model. In general, this consideration is more applicable the more it falls into the context of the digital transformation [the use of technologies to fully digitalize aspects of the business

(Westerman et al. 2014)].



23.7



Insights and Experiences



An enterprise IT department with all the knowledge discussed above appears to be

perfectly equipped to practice tamed agility and the New School of IT. But it is also

useful for the enterprise IT department—or a sufficient number of its members—to

have gained experience and learned some lessons, including the following:

• No one-size-fits-all projects: Every project is different. This does not mean that

no generally applicable methods and instruments exist. However, it means that

changes are required every now and then, that flexibility is essential, and that

there is no reason for method and process dogmatism.

• Central importance of expectation management: People want to know what

awaits them, even if we are only talking about new software. This means one

has to explain what is happening to them. Expectations are only adjusted if the

explanations are also understood. Expectation management therefore means to

explain circumstances as long and as thoroughly as it takes to make them

understood, and not only as long as it should take to make them understood.

• Lean and good-enough software: Ideal solutions cannot be built, especially not

at first try. Most of all they are too expensive. Software that fulfills its purpose is

entirely sufficient, pays off more quickly, and is readily used. Additional

financial resources may then be made available in order to get closer to ideal

software, even though this is usually unattainable in the end.

• People want to be valued and included: In the end, people do the work in a

project. People want to be appreciated for their contribution to project work, and

they want to know how their contributions are integrated into the overall system.



292



23



A New Skill Set



• Communication is the key: Whether we are talking about delays or quality

problems, project success, or sensitive measures—at least half of a project’s

success depends on appropriate communication. Being able to talk to the right

people in the right order and suitable tonality is eminently important.

All experience shows that software projects succeed or fail with the ability of all

stakeholders to correctly grasp, understand, assess, and implement the system

context and system requirements. Especially in socio-technical systems in the

context of the New School of IT, which are closely interwoven with existing

business process and technology landscapes, the ability of the team members to

communicate is central: Based on the most well-founded possible technology and

domain knowledge, they have to make the right decisions about prioritizing

requirements, designing system structures, adapting business processes and the

integration of many different components and interfaces.

With the Interaction Room, we have introduced a method that supports the

understanding, evaluation, and discussion of many different aspects of a system.

True to the agile philosophy, it encourages healthy pragmatism with a focus on the

aspects that are essential for understanding the project and ensures that value and

risk drivers remain in view during the entire project term. The adVANTAGE

contract model ensures that such a pragmatic, agile approach does not remain a

theoretical ideal that is forced back into an advance planning corset by classic

delivery contracts. Since adVANTAGE gives both the client and the supplier leeway for adjustments but fairly distributes risks at the same time, the contract model

ensures that agility can actually be practiced in a flexible innovation process guided

by value and risk considerations.



References

Akella J, Buckow H, Rey S (2009) IT architecture: Cutting costs and complexity. http://www.

mckinsey.com/business-functions/business-technology/our-insights/it-architecture-cuttingcosts-and-complexity. Accessed 1 Mar 2016

Bass L, Weber I, Zhu L (2015) DevOps: A software architect’s perspective. Addison-Wesley

Davenport TH, Patil DJ (2012) Data scientist: The sexiest job of the 21st century. Harvard

Business Review 90(10):70–76

Duvall PM, Matyas S, Glover A (2007) Continuous integration: Improving software quality and

reducing risk. Addison-Wesley

Griebe T, Gruhn V (2014) A model-based approach to test automation for context-aware mobile

applications. In: Kim S, Hung CC, Hong J (eds) SAC 2014: Proc 29th Annual ACM

Symposium on Applied Computing, pp 420–427. doi:10.1145/2554850.2554942

Gruhn V, Schäfer C (2015) BizDevOps: Because DevOps is not the end of the story. In: Fujita H,

Guizzi G (eds) SoMet 2015: Proc 14th Intl Conf on Intelligent Software Methodologies, Tools

and Techniques. Communications in Computer and Information Science, vol 532. Springer,

pp 388–398. doi:10.1007/978-3-319-22689-7_30

IREB e.V. (2016) Certified professional for requirements engineering (CPRE). https://www.ireb.

org/en/cpre/basics/. Accessed 1 Mar 2016

Westerman G, Bonnet D, McAfee A (2014) Leading digital: Turning technology into business

transformation. Harvard Business Review Press



Outlook: Twelve Hypotheses



24



Enterprise IT must and will undergo tremendous change. This change is not triggered by one single megatrend, buzzword, or idea. Rather, numerous developments

are intertwining, jointly causing radical change. This change can be formulated in

twelve hypotheses:

• IT is no longer driven, but becomes the driver: The importance of IT in the

company will grow beyond merely supporting business. It is going to determine

new business models. More and more often, new products and services will be

the result of new possibilities in IT. All of a sudden, business development takes

place in enterprise IT.

• The world goes mobile: The centralist world view of IT starts to totter.

Infrastructure and applications are needed where business happens, not the other

way around. Mobility will not merely constitute a specialization of IT, but

become the basic pattern for the (further) development of IT.

• Application development for the mobile world is a new discipline: IT for

mobility is far more than bridging the physical distance between mobile devices

and companies. Software engineering for mobile applications is more difficult

than software engineering for stationary software. Complexity increases and has

to be managed.

• Neat interfaces are not just for games: A pleasant user experience will not be

reserved for consumer applications and gaming. Users have become accustomed

to elegant, well-functioning interfaces, and expect these in business life and

daily work as well.

• What is “in” today is “out” tomorrow: The boundaries between enterprise IT

and external contractors are going to shift significantly. More and more often,

the risks of application development and operations are being passed on to

contractors. They become specialists in the industry of the client. Internal IT

becomes specialized in technically driven business development, requirements

engineering, and test management.

© Springer International Publishing Switzerland 2016

M. Book et al., Tamed Agility, DOI 10.1007/978-3-319-41478-2_24



293



294



24



Outlook: Twelve Hypotheses



• The client and contractor share joy and pain: New cooperation models will

define relationships with contractors. The client and contractor become partners

and commit to lean processes, lean software, and lean operating models. Risks

and opportunities are shared. The price is not determined by the size and

complexity of the application, but by efficiency as the ratio between effort and

benefits.

• Everything in software development becomes agile, including the price: The

change in cooperation between the client and contractor in custom development

leads to new commercial models. The time and materials basis is too risky for

the client. Fixed prices are not affordable due to high risk surcharges. As a

result, commercial models are designed based on agile development processes.

• Software development becomes value-oriented: There is only one true measure of productivity in application development: few function points per desired

functionality. This becomes the control quantity in portfolio planning and the

determination of success. Efficiency is the ratio of the benefits achieved to the

effort expended. This leads to a focus on value-added features.

• Software development increasingly becomes a process of gaining insights:

All progress in software engineering notwithstanding, specifying information

systems fully is not possible and therefore will not be attempted. Instead one has

to accept that some insights and requirements will not be known until late in the

process.

• Knowledge becomes a central element of application development: The

knowledge in the minds of the people in the business and IT departments is

complementary. Value-added applications are created when both sides are

willing and able to exchange and combine this knowledge. This requires mutual

respect and communication skills.

• Development and operations become one: The increasing agility of application development radiates to deployment and operation. Short iteration cycles

and the rapid availability of new software versions are only useful if they can be

put into production quickly as well. The divides between application development and operations are bridged by necessity. Development operation organizations will be created for particularly dynamic domains.

• IT remains human—but differently: Automation, increased efficiency,

mobility, agility, and flexibility—all the changes and evolution in IT also mean

that the role of people in IT is going to be transformed. Social, communication,

and creative skills are needed in addition to technical expertise in order to handle

the new opportunities and reap the full benefits.

The New School of IT is a novel challenge and new responsibility rolled into

one for enterprise IT. Rising to the challenge requires not only pragmatic methods

and instruments, but also most of all capable people such as domain and technology

experts who contribute their ideas, talk to each other, respond to each other, and

look for new business and technical solutions.



Appendix A

Interaction Room Workshop Agendas



A.1



Interaction Room Workshop Agendas



The agendas suggested below can serve as guidelines for conducting Interaction

Room workshops. The specified timeframe should only be interpreted as a rough

orientation. Depending on the complexity of the project and which questions have

to be resolved most urgently, it is conceivable to only apply certain elements of the

methodology, or to spread the workshops over several days or even weeks. For

example, it can be helpful to plan dedicated workshop days for the population of

individual canvases, conducted at intervals of several days to give the stakeholders

time for reflection, more in-depth understanding and preparation between the

workshops.



A.1.1 IR:digital Workshop Agenda

Day 1

9:00 a.m.

9:30 a.m.

10:30 a.m.

12:00 p.m.

1:00 p.m.

2:00 p.m.

3:00 p.m.

4:30 p.m.

5:00 p.m.

5:15 p.m.



Introduction of the stakeholders, overview of the IR:digital

methodology

Establishing the workshop objective

Population of the partner canvas

Lunch break

Annotation of the partner canvas, discussion, and establishment of no

more than the five most important partners

Technology overview (presentation)

Population of the physical object canvas (focus on identification of

the OoIs)

Annotation of the physical object canvas, discussion, and establishment of no more than the ten most important OoIs

Summary of the day, establishing the focal points for day two

Conclusion of the day.



© Springer International Publishing Switzerland 2016

M. Book et al., Tamed Agility, DOI 10.1007/978-3-319-41478-2



295



296



Appendix A: Interaction Room Workshop Agendas



Day 2

9:00 a.m.

11:00 a.m.

12:00 p.m.

1:00 p.m.

2:30 p.m.

3:30 p.m.

4:00 p.m.

5:00 p.m.

5:30 p.m.

6:00 p.m.



Population of the physical object canvas (focus on life cycles of the

most important OoIs)

Technology overview (presentation)

Lunch break

Population of the touchpoint canvas for the five most important

partners (including establishment of the touchpoint lanes)

Annotation of the touchpoint canvas, discussion

Establishing the top five digitalization proposals

Parallel preparation of “press releases” for the top five realization

proposals

Presentation of the “press releases”

Summary of the results, feedback session

Conclusion of the day.



A.1.2 IR:scope Workshop Agenda

Day 1

9:00 a.m.

9:30 a.m.

10:30 a.m.

12:00 p.m.

1:00 p.m.

3:00 p.m.

3:30 p.m.

4:45 p.m.

5:00 p.m.



Introduction of the stakeholders, overview of the IR:scope

methodology

Establishing the workshop objective, formulating the “press release”

Population of the feature canvas, annotation and prioritization of the

features

Lunch break

Population of the process canvas1

Coffee break

Annotation and discussion of the process canvas

Brief summary of the insights, establishing the focal points for day 2

Conclusion of the day.



Day 2

9:00 a.m.

9:15 a.m.

10:30 a.m.

12:00 p.m.

1:00 p.m.

2:00 p.m.

3:00 p.m.



1



Recap of key insights from day 1 and plan for day 2

Completion of the object canvas

Annotation and discussion of the object canvas

Lunch break

Completion of the integration canvas

Annotation and discussion of the integration canvas

Coffee break



Depending on the project requirements, another canvas may also be chosen as the leading canvas.



Appendix A: Interaction Room Workshop Agendas



3:30 p.m.

4:30 p.m.

5:00 p.m.



297



Analysis of the overall picture, elimination of gaps/inconsistencies,

first more in-depth examinations

Summary of the insights, establishing the next steps

Conclusion of the day.



A.1.3 IR:mobile Workshop Agenda

Day 1

9:00 a.m.

9:30 a.m.

10:30 a.m.

12:00 p.m.

1:00 p.m.

3:00 p.m.

3:30 p.m.

4:45 p.m.

5:00 p.m.



Introduction of the stakeholders, overview of the IR:mobile

methodology

Establishing the workshop objective, formulating the “press release”

Formulating, presenting, and weighting the personas

Lunch break

Population of the portfolio canvas

Coffee break

Annotation and discussion of the portfolio canvas

Brief summary of the insights, establishing the focal points for day 2

Conclusion of the day.



Day 2

9:00 a.m.

9:15 a.m.

11:00 a.m.

12:00 p.m.

1:00 p.m.

3:00 p.m.

3:30 p.m.

4:30 p.m.

5:00 p.m.



Recap of the key insights from day 1 and the plan for day 2

Population of the touchpoint canvas

Annotation and discussion of the touchpoint canvas

Lunch break

Population of the interaction canvas

Coffee break

Annotation and discussion of the interaction canvas

Summary of the insights, establishing the next steps

Conclusion of the day.



A.1.4 IR:tech Workshop Agenda

Day 1

9:00 a.m.

9:30 a.m.

10:30 a.m.

12:00 p.m.



Introduction of the stakeholders, overview of the IR:tech methodology

Establishing the workshop objective

Population, annotation, and discussion of the feature canvas

Lunch break



298



Appendix A: Interaction Room Workshop Agendas



1:00 p.m.

3:00

3:30

4:45

5:00



p.m.

p.m.

p.m.

p.m.



Population of the object,2 integration, and process canvas (current

state)

Coffee break

Annotation and discussion of the canvases (current state)

Brief summary of the insights, establishing the focal points for day 2

Conclusion of the day.



Day 2

9:00 a.m.

9:15 a.m.

10:30 a.m.

12:00 p.m.

1:00 p.m.

2:30 p.m.

3:00 p.m.

3:30 p.m.

4:30 p.m.

5:00 p.m.



2



Recap of the key insights from day 1 and the plan for day 2

Population of the object canvas (target state)

Population of the integration canvas (target state)

Lunch break

Population of the process canvas (target state)

Annotation of the target canvases

Coffee break

Discussion of the canvases, deriving technology implementation

potential and hurdles

Summary of the insights, establishing the next steps

Conclusion of the day.



Depending on the project requirements, another canvas may also be chosen as the leading canvas.



Appendix B

Interaction Room Annotations



B.1 Interaction Room Annotations

The annotations that were briefly introduced in the chapters on the individual

canvases are presented and explained in more detail in the following sections. This

list is intended to help the IR coaches choose the most suitable annotations for a

specific context. In addition to describing the meanings of the annotations, detailed

questions are also listed to help coaches with precisely pinpointing and specifying

the annotated issues in their project context.



B.1.1 Value Drivers

Value drivers are indicated by the symbols shown in Fig. B.1.



Business value



User value



Innovation



Fig. B.1 Value driver annotations



B.1.1.1 Business Value

From a service provider’s perspective, value creation by a system or process

element can express itself in many ways. While financial contributions to the sales

objective are the most obvious and easiest to measure (e.g., sales via a shop

platform), contributions to other business objectives can be more difficult to

comprehend, which means they can be easily lost in prioritization approaches.

Contributions to objectives such as customer loyalty, the external image, or quality

are difficult to measure may not be directly attributable to concrete features. The

business value annotation encourages the explicit exploration of these points.



© Springer International Publishing Switzerland 2016

M. Book et al., Tamed Agility, DOI 10.1007/978-3-319-41478-2



299



300



Appendix B: Interaction Room Annotations



The following questions can be used to state the annotated business value more

precisely:

• What system/process element has a particular influence on the business value?

• What company objectives are positively influenced by the annotated element,

which ones negatively? (customer loyalty/sales/competition/market share/

external image/marketing/sustainability/company development/costs/quality/

productivity/other);

• What is required to achieve a positive influence or prevent a negative influence?



B.1.1.2 User Value

A question of added value also arises from the perspective of the system’s user.

While the expectations of the user and service provider may complement each other

in some cases (e.g., the user benefits from a certain function, the provider from the

usage fee), they may also contradict each other in other cases (if the user expects a

function that is unattractive for the provider, e.g., the link to a comparison portal).

To uncover such areas of conflict, the perception of the user is highlighted by the

distinct user value annotation.

Since value dimensions as clear and generally applicable as the various company

objectives used for the business value annotation typically cannot be defined for

users, the Kano (1984) classification is used here. The intensity of value creation is

defined according to whether the annotated system or process element is a must-be,

one-dimensional, or attractive quality, i.e., a characteristic that is expected as a

matter of course, one that is perceived to improve performance, or one that

positively surprises the user and may enhance acceptance of the system.

To state this assessment more precisely, the following questions should be

answered for each user value annotation:

• What system/process element has a special influence on user value?

• What are the expectations for this element? (basic/performance/enthusiasm

characteristic);

• What is required to achieve a positive influence or prevent a negative influence?



B.1.1.3 Innovation

The innovation annotation identifies process sections, system elements, features, or

general ideas that are especially innovative, for instance novel from a business or

technical perspective. It therefore constitutes an interface between value and effort

drivers:

Innovation implies a special business value on the one hand—if there was no

prospect of this, one would hardly be inclined to expend the effort and accept the risk of

the innovation (see below). The innovation annotation usually also identifies a user

value, often even in the sense of an enthusiasm characteristic. The feature offers a novel

function or realizes a known function in a new way that positively surprises the user,

thereby differentiating itself from the competition and improving user acceptance.



Appendix B: Interaction Room Annotations



301



But on the other hand, the innovation annotation also implies effort: Implementing

an innovative solution is usually more resource-consuming than using established

solution templates, since new approaches to solutions first have to be developed and

evaluated. Risks are also inherent in every innovation—regarding the feasibility of

the technical implementation, the time and budget required for implementation, and

the ultimate acceptance by the user.

This combination of characteristics makes the innovation annotation an

important anchor point for discussions. It requires especially diligent estimates of

effort and prioritization as well as particularly competent development and quality

assurance.

For a more precise definition, the following questions should be answered for

every innovation annotation:

• What system/process element constitutes a special innovation?

• What is the innovation in this element?

• Is it a technology or business innovation? Is it disruptive in nature?



B.1.2 Effort Drivers

Effort drivers are indicated by the symbols shown in Fig. B.2.



High use



Time constraint



Accuracy



Reliability



Security



Usability



Attractiveness



Flexibility



Mobility



Automation



Manual task



Policy constraint



Complexity



Invariability



Deprecation



Need for improvement



External resource



Fig. B.2 Effort driver annotations



Tài liệu bạn tìm kiếm đã sẵn sàng tải về

6 Knowledge of Business Processes, Business Models, and Partnerships

Tải bản đầy đủ ngay(0 tr)

×
x