27.03.2014 Views

SEKE 2012 Proceedings - Knowledge Systems Institute

SEKE 2012 Proceedings - Knowledge Systems Institute

SEKE 2012 Proceedings - Knowledge Systems Institute

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

As the researcher became more embedded in the<br />

problem domain, observations revealed that a lack of justin-time<br />

knowledge during processes related to the<br />

movement of application s oftware to production caused<br />

process delays and degraded communication to upstrea m<br />

and downstream stakeholders. When participants in the<br />

process did not have the knowledge needed to execute their<br />

step in the process, the process stalled and often additional<br />

team members were brought into the situation. This<br />

increase in time and number of human resources increases<br />

the cost of e xecuting the process. Tac it knowledge is<br />

created and shared during process execution, as well a s<br />

creation of new explicit knowledge.<br />

B. Phase 2<br />

Based on the results of the first cycle, the second cycle<br />

research question was defined as: How will organizational<br />

and process changes increase knowledge sharing and<br />

collaboration both within infrastructure support team s and<br />

between those teams and ot her software engineering<br />

stakeholders?<br />

For this phase, the scope chosen was the set of activities<br />

required to move an application from one data center to a<br />

new primary data center on a different set of ph ysical<br />

infrastructure. Frequently, applications must make coding or<br />

other changes to adhere to new technology standards that<br />

are instituted at the new center. The process of bringing<br />

business applications up to those new standards was chosen<br />

as a very specific area withi n which to study and attem pt to<br />

improve team collaboration and knowledge sharing.<br />

Specific deliverables of the process included the following<br />

artifacts: a technical architecture requirements document, a<br />

technical architecture design that includes required<br />

infrastructure, and an envi ronment build docum ent that<br />

documents configuration re quirements for syst em<br />

administrators to follow when building machines for the<br />

target application.<br />

Problems with this process included frequent handoffs,<br />

lost time when information is s hared but not receive d,<br />

sequential steps, bottlenecks, and multiple points of contact.<br />

All of these problems are barri ers to knowledge sharing.<br />

Improvements to the process are e xpected to reduce cycle<br />

time for the process, reduce error, increase satisfaction both<br />

with the development teams and the infrast ructure support<br />

teams, and i ncrease knowledge sharing and collaboration<br />

between subject matter experts and between service<br />

providers and their internal customers.<br />

While participating in t he process im provement<br />

activities, the role of the acti on researcher in this study was<br />

to contribute to the de sign of a collaborative technology to<br />

support a stre amlined process. A n important part of this<br />

process analysis was analyzing the data flows in and ou t of<br />

the process. An i nventory exercise was conducted,<br />

identifying what data and inform ation was needed at each<br />

point in the fl ow of the process. Data owne rs and data<br />

receivers were also ide ntified. T he process timeline was<br />

identified as one to six months depending on the technical<br />

requirements of t he project and the individuals involved.<br />

With multiple handoff points, there was increased time and<br />

the potential for error i ntroduced. The process was very<br />

human-intensive, so progression was directly dependent on<br />

the availability, responsiveness, and knowledge of each<br />

person in the process.<br />

Resulting recommendations for process improvement<br />

following evaluation of this phase included the following:<br />

Reduce the number of a nalysts involved. By<br />

combining roles, handoffs between project<br />

initiation and implementation is eli minated. This<br />

also increases the likelih ood that the inform ation<br />

and knowledge used for infrastructure<br />

configuration and setup is m ore accurate, as the<br />

same person has accountability from the beginning<br />

of the process until the end.<br />

Automate data collection th roughout the process<br />

cycle. T his ensures consistency of data collected<br />

across process iterations. It a lso ensures that input<br />

received across project im plementations will be<br />

shared.<br />

IV. CONCLUSION<br />

Observations in the first cycle revealed that, in a n<br />

environment where revenue generating applications are<br />

given priority for development resources, limited support<br />

for development of a knowledge sharing system is available.<br />

A creative framework that utilizes existing technology with<br />

minimal development for a very specific problem domain is<br />

the most effective way to address cross-boundary<br />

knowledge sharing concerns. However, to be most effective<br />

the scope must be bounded by specific functional processes,<br />

which are the ties that bind a community of practice.<br />

In addition to the technology layer, an effective approach<br />

to increased knowledge sharing and col laboration must<br />

consider the multiple processes that m ake up a knowledge<br />

workers daily context, and the knowledge that must flow in<br />

order to support that workfl ow. The organization of people<br />

and process must be considered in order for kn owledge<br />

creation to be efficient and effective. The layers in the<br />

knowledge management sandcone depicted in Fig. 1 should<br />

be reordered as shown in Fig. 2. P rocess must first enable<br />

knowledge sharing, with organizational changes considered<br />

a part of process improvement. T he technology layer c an<br />

then be applied. Only then is there enablement for cultural<br />

change.<br />

703

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!