Monthly Archives: October 2011

Running prototype demonstrations in DSDM

Posted in Agile Software Development by

In order to get the best value out of prototype demonstrations, the guidelines below should be followed.

The demonstrators should prepare the audience for any prototype demonstration session. The objectives of the session should be clearly stated together with the known limitations of what will be seen. It can be too easy to assume that, since one or two users have been involved in the development of a prototype, the rest of the user community are as knowledgeable about what is going on. Indeed, the Ambassador Users will talk to their colleagues but this communication channel should not be totally relied upon until working software has been demonstrated to the wider user population, as it is often difficult to explain what has not been seen – the reason why DSDM is the way it is.

During the session, discussion should be encouraged. Putting the prototype through its paces at such a speed that the users cannot see what may be expected of them in the future is worse than useless. The development team may come away from the session feeling reassured that they are following the right track, whereas all that has happened is that any comments have been stifled.

The Scribe should record all comments made during the demonstration. Otherwise, since the focus of the developers  and the users will be on the behaviour of the prototype, some feedback may be forgotten.

Source:

Testing prototypes in DSDM

Posted in Agile Software Development by

DSDM prototype serves two different roles:

  • it is a partial build of the system that will be delivered
  • it is a technique for gathering information to clarify functional or non-functional requirements.
Different test criteria apply depending on the role the prototype is serving:
  • To the extent that the prototype represents part of the functionality of the final system, a test pass/fail can be based on whether or not the test result from the prototype matches an expected result based on the known  requirements.
  • To the extent that the prototype is intended to clarify requirements, the criterion for test success or failure is whether or not the prototype generates the expected information. This is exploratory. The expected
    information cannot be predefined in the same way that an expected result can be. The test of the prototype is being used to expand the knowledge and understanding of the prototype builder. The test is successful if this
    is achieved in the area under investigation.

A single prototype may serve in both roles and therefore should be tested against both criteria.In the Functional Model and Design and Build Iteration phases, prototyping generally iterates up to three times in line with the timeboxing process.  The prototypes that are produced can fall within any one of four categories. Prototypes of all categories can be tested against a mixture of “expected result” and “expected information” criteria.

This iterative lifecycle is summarised in the table below, which shows the categories of prototype and the type of testing criteria that will tend to apply at each iteration.

Iteration within Timebox
Prototype Category Investigation Refinement Consolidation
Business EI EI/ER ER
Usability EI EI/ER ER
Performance EI EI/ER ER
Capability EI EI/ER ER
Testing criteria for the categories of prototype (EI = Expected Information, ER = Expected Result)

Managing the prototyping process in DSDM

Posted in Agile Software Development by

This section discusses a number of key issues that surface in the management of the prototyping process.

Managing iteration

There are several aspects that have to be managed in order to achieve successful passage through prototyping
activities. These are:

  • timeboxing
  • change control
  • configuration management
  • user involvement
  • quality assurance of products
  • learning from earlier iterations.

Strict adherence to timeboxes ensures that prototyping cycles are not allowed to lose their focus on delivering to the agreed priorities and that the quality of products is assessed within each timebox.

The procedures for change control must enable change to be introduced quickly and effectively. Over-prescriptive procedures will slow down development.

In order to be able to backtrack to a previous prototype, strong configuration management must be enforced. For instance, users may decide that a previous user interface was preferable to the current one or that the functionality is
progressing in the wrong direction to meet their most immediate business needs. In such circumstances, it must be possible to move backwards smoothly and for all developers to be sure of which version or variant is the current one.

While prototyping without user involvement is impossible, it is important that the users do not drive the development in the wrong direction through lack of knowledge outside their own sphere of activities. Senior user management must
ensure that a representative set of users is included in prototyping activities.
To ensure that prototyping progresses as fast as possible, it is important that the selected user representatives are available at all times when they are needed.
By keeping the team consistent throughout development, the team can learn from previous prototyping activity and so improve the quality of the products and the efficiency of working.
The number of iterations
As a general rule, it is recommended that three iterations be allowed – and that they are aligned to the timebox process:
  • investigation to see whether the right approach is being taken
  • refinement to build on the comments and feedback after the investigative prototype
  • consolidation to fully satisfy the objectives of the prototype.

This will mean three prototype cycles leading to a part of the Functional Model and three prototype cycles leading to a part of the Tested System. However, if the nature of the application and/or the technical environment mean that functional modelling and design and build merge then the number of prototypes will obviously be reduced. It is generally advisable to avoid more than three iterations since this can encourage a feeling that things can be left until later.

Collaboration and consensus

Prototyping requires collaboration and consensus between the developers and the users, as distinct from a contract negotiated at the start of the process, which can frequently be a source of confrontation between developers and users.

Choosing what to prototype

When producing the Development Plan, the project manager and the team decide where the categories of prototypes (and any combinations of them) are most appropriate, given the business and technical environment.

Horizontal vs. vertical approach

Having chosen the area to prototype, the DSDM team must first choose whether to build their prototypes in a horizontal or a vertical way. The choice is simply a way of slicing up the application, so any category of prototype may appear in a
horizontal or a vertical application slice.

With a horizontal approach the whole system is first built at a high level to check how it will cover the scope of the project. The detail is filled in later. With a vertical approach a section of the computer system is built incrementally until
it is fully understood, then the next section is started.

Both approaches have their advantages and disadvantages. If the whole concept of the system/business area is new then a horizontal approach may be safer. If the overall structure of the system is well understood but the detail is unclear then a vertical approach might be better. One advantage of the vertical approach is that it allows incremental deployment of subsystems for immediate business benefit. Generally, systems will be built using a combination of  horizontal and vertical approaches.

Source:

Prototyping cycles in DSDM

Posted in Agile Software Development by

Each of the development phases (the Functional Model and the Design and Build Iterations) contains iteration through
prototyping. There are basic controls that must be implemented in order to ensure the success of these activities.
These controls are built into a prototyping cycle and are aligned to the cycles within the timebox process.

A prototyping cycle passes through four stages:

  •  identify prototype
  • agree plan
  • create prototype
  • review prototype.
Identify prototype
Before embarking on building a prototype, what is to be prototyped must be clearly identified. This decision will be based on the relative priorities given to the functional and non-functional requirements. Having partitioned the application into possible prototypes, it should be made clear which are the essential parts of each prototype and which are “extras” through applying the MoSCoW rules. This will limit the scope of activity in each prototyping cycle and determine the priorities of the developers and users who are building the prototype.
The prototypes can be selected by various criteria: business area, basic processing required, the user groups, information accessed and the criticality of the processing to the final system.
The results of reviews from previous prototyping cycles provide valuable information when identifying the prototypes to be developed.

Acceptance criteria for the prototype should be defined in outline before any development takes place in order to lead the prototyping activity in the most useful direction.

Agree plan

The Development Plan in its schedule of timeboxes sets a limit on the time to be spent on each prototype. The team must agree the detailed plan for the current prototyping cycle. This includes prototyping the Must Haves first. Lesser parts will be dealt with if time is available.

The plan should not be allowed to slip unless significant problems arise, e.g. unexpected and dramatic changes in scope. However, such problems will probably require halting all activity temporarily while the project direction is
rethought.

It is important that the reasons for the time limit are clearly understood by the users. It is their priorities that will identify the essential components of a prototype. They must be made fully aware that asking for in-depth investigation of a particular area may mean that they have to decide what other area they can do without.

Create prototype

The prototypes are usually developed collaboratively with users. However later in development where issues such as performance are being addressed, the users will take a back seat.

Prototypes are not necessarily automated. For instance, early in development, a paper-based storyboard may be more cost-effective and flexible than a fully automated user interface to unexplored functionality. Both business and technical imperatives will drive the choice of prototyping medium.

Review prototype

Each prototype should be reviewed by the prototyping team (both developers and users) and other interested parties, where appropriate, (e.g. business analysts and senior user management) to ascertain:

  • which objectives it has met successfully
  • which areas will have to be included in later development
  • which missed areas can be safely postponed (or possibly incorporated in another project) in order to achieve the project’s timescales
  • the acceptability of what has been produced.

As well as verifying that the relevant quality criteria have been met, there are two major aims of the review:

  • to ensure that the development team are following the right track
  • to get the users at all levels to buy in to the completed and future work.
Sources:

Categories of prototypes as recommended by DSDM

Posted in Agile Software Development by

Dynamic Systems Development Method (DSDM) is a framework for delivering business solutions that relies heavily upon prototyping as a core technique, and is itself ISO 9001 approved. DSDM uses the word ‘prototyping’ because that is the industry ‘standard’, but they are not truly prototypes: they are partial system components. A DSDM prototype is not ‘all done by mirrors’, but is built using the platform on which all the development work is done, and meeting all the required  standards. In other words, the prototypes are intended to be evolutionary {may be evolved horizontally (breadth then depth) }rather than throwaway {each section is built in detail with additional iterations detailing subsequent sections}: they will evolve into the delivered system. Of course, there will be occasions when it is better to throw something away and start again, but the aim at all times should be to build on what is there already.

Four categories of prototype are recommended by DSDM that are used at different stages of development, and have very different purpose. They are:

  • Business prototypes
  • Usability prototypes
  • Performance and capacity prototypes
  • Capability / design prototypes

While the purpose of each prototype category is different, it will often be the case that some combination of them will be used. For instance, a common combination is the business and usability prototype, but this approach should not be taken as a matter of course. If the functionality is at all complex, it may be better to get it right before worrying about the presentation aspects. Conversely, if there is no standard for user interface design, it is good idea to get some usability prototyping done first. The categories of prototype to be built in a timebox should be decided at its outset based on the aims of the timebox.

Business prototypes

  • Purpose:
    A business prototype demonstrates the developers’ understanding of the functional requirements. The developers can use this prototype to demonstrate to the users how the final system could work. This will enable the users to better formulate their real business requirements.
  • Description:
    A business prototype is designed only to demonstrate how the business processes are supported by the computer system. It is not designed to look good or to be particularly user-friendly: nor will secondary functionality, such as error checking, necessarily be implemented. It is very important that the users understand the purpose of demonstrating a business prototype.
  • How used:
    A business prototype enables the developers to demonstrate to the users their understanding of the key system requirements early in the project. This early prototype can then be evolved to cover more of the functionality and to incorporate non-functional aspects. Typically, the developer will use a scripted demonstration to ensure that the functionality is demonstrated to best effect. Any discrepancies between the developers’ understanding and the business requirements are noted.
  • Position in the project lifecycle :
    The first business prototype will be demonstrated as early as possible in the project lifecycle (possibly as early as the Feasibility Study, but no later than early in the Functional Model Iteration). This will confirm the right system is being built. First, the fundamental functionality of the system will be demonstrated. Later on, more detailed functional requirements can be demonstrated and/or other areas can be business prototyped.The final business prototype will clearly demonstrate to the users how the system will work. It may not look very pleasing, and have lots of missing functionality, but it will ensure the right system is being built.
Usability prototypes
  • Purpose: A usability prototype ensures the computer system will be as easy and intuitive to use as possible. Users should enjoyusing the system and it should be obvious how the system can be used. If this is done well, end-users will need less training before they can use the system effectively, while still having a good understanding of the full capabilities of the system.
  • Description:
    Well-designed computer systems are simple and straightforward, easy to learn and understand, and fun to use. It is impossible to achieve usability without trying the system out on the users. A usability prototype demonstrates how the user interacts with the system. It may not actually automate the business process. For example a form is displayed, the user adds data, but nothing is written to disk. The user can understand how to move around the system and how the  interface works.
  • How used:
    A user carries out a number of tasks using the prototype.  Any difficulties encountered by the user in achieving those tasks are noted so that the usability of the system can be improved.Contrast this with the business prototype where the developer will typically demonstrate the system, to show the functionality only. A business prototype may be rather user-unfriendly so it is better if the developer removes the need for a user to learn the interface.There is a danger of building a usability prototype that cannot be developed into the final system. Developers must take care not to create any unrealistic expectations.
  • Position in the project lifecycle:
    usability prototype may be built during either the Functional Model Iteration or the Design and Build Iteration, but there are many benefits in building it as early as possible. For a computer system to be easy to use, it must have a simple conceptual  model that the users can easily understand to help them move around the system.
    A usability prototype confirms that a good conceptual model has been chosen. If this is not done early on in the project and the model is wrong, it could adversely affect the design of the system. To reduce the risk of this, a high-level usability prototype should be built in the Functional Model Iteration or early on in the Design and Build Iteration. More detailed usability, such as the buttons in a window, can be designed later. If standards for the user interface are chosen early on, then all programs can be built to the agreed standard, reducing the need for rework. Having a stable installation Style Guide in place before prototyping commences on any project would help even more.In practice there are many benefits in combining the business and usability prototypes.
Performance and capacity prototypes
  • Purpose:
    A performance and/or capacity prototype ensures that the final computer system will be able to handle the full peak time workload required. While users may be involved, this category of prototype is typically for the benefit of the developers.
  • Description:
    This prototype deals with the non-functional aspects of the system, such as concurrent transaction volumes, data loading, overnight batch reports, and month end batch runs, as well as on-line screen performance. Checks will be made that the target system has enough resources to function adequately in the live environment, even when other systems are competing for machine resources.
  • How used:
    Performance and capacity prototypes are usually developed for the benefit of the developers to ensure the computer system can meet its desired performance requirements. A test scenario is set up and repeated while changing different aspects of the system to see how it performs. This process is best automated so that it is easily repeated, but it can be
    done manually where a group of users follow a script. The system is monitored to see where any “bottlenecks” occur.
  • Position in the project lifecycle:
    This category of prototype is typically used during Design and Build Iteration, after the required functionality has been determined. Often existing business prototypes will be used for performance testing. Sometimes early in the project design, the developers may be concerned as to whether a certain piece of functionality can be provided within the
    constraints of the machine/network environment. In this case, a performance and capacity prototype can be specially built to check where the limits might be. Such a prototype might look very different from the final system.
Capability/technique prototypes
  • Purpose:
    Developers often have a range of design options and sometimes a choice of tools to use. A capability/technique prototype tries out a particular design approach or tool to help in choosing between these options.
  • Description:
    This category of prototype is typically limited in functionality and is for the benefit of the developers only. The prototype demonstrates the capabilities and limitations of an approach, a technique or a tool to the developers.
  • How used:
    The developer builds a number of prototypes and weighs up the benefits of each technical approach.
  • Position in the project lifecycle:
    Although selection of a tool is usually made outside any one particular project, a tool capability prototype can be developed during the Feasibility Study to ensure that the potential technical approach will be soundly based. Later design capability/technique prototypes are created during the design phase of a project.Different designs or tools are used to build prototypes that represent the options available to the developer. Each prototype can then be assessed and the best approach, technique or tool selected.
Sources:

Types of prototyping

Posted in Agile Software Development by

View Information System Prototyping

Throwaway prototyping
 Also called close-ended prototyping. Throwaway or Rapid Prototyping refers to the creation of a model that will eventually be discarded rather than becoming part of the final delivered software. After preliminary requirements gathering is accomplished, a simple working model of the system is constructed to visually show the users what their requirements may look like when they are implemented into a finished system.

The most obvious reason for using Throwaway Prototyping is that it can be done quickly. If the users can get quick feedback on their requirements, they may be able to refine them early in the development of the software. Making changes early in the development lifecycle is extremely cost effective since there is nothing at that point to redo. If a project is changed after a considerable work has been done then small changes could require large efforts to implement since software systems have many dependencies. Speed is crucial in implementing a throwaway prototype, since with a limited budget of time and money little can be expended on a prototype that will be discarded.Another strength of Throwaway Prototyping is its ability to construct interfaces that the users can test. The user interface is what the user sees as the system, and by seeing it in front of them, it is much easier to grasp how the system will work.

One disadvantage with throw-away prototyping is that developers may be pressurised by the users to deliver it as a final system! Another issue is that all the man-hours of putting together the throw away prototypes are lost unlike the evolutionary approach. But the benefits may outweigh the disadvantages.

One method of creating a low fidelity Throwaway Prototype is Paper Prototyping. The prototype is implemented using paper and pencil, and thus mimics the function of the actual product, but does not look at all like it. Another method to easily build high fidelity Throwaway Prototypes is to use aGUI Builder and create a click dummy, a prototype that looks like the goal system, but does not provide any functionality.

Steps:

  1. A preliminary project plan is developed
  2. An partial high-level paper model is created
  3. The model is source for a partial requirements specification
  4. A prototype is built with basic and critical attributes
  5. The designer builds
    –the database
    –user interface
    –algorithmic functions
    –algorithmic functions
  6. The designer demonstrates the prototype; the user evaluates for problems and suggests improve
  7. This loop continues until the user is satisfied.
Evolutionary prototyping
Evolutionary Prototyping (also known as breadboardprototyping) is quite different from Throwaway Prototyping. The main goal when using Evolutionary Prototyping is to build a very robust prototype in a structured manner and constantly refine it. “The reason for this is that the Evolutionary prototype, when built, forms the heart of the new system, and the improvements and further requirements will be built.When developing a system using Evolutionary Prototyping, the system is continually refined and rebuilt.Evolutionary Prototypes have an advantage over Throwaway Prototypes in that they are functional systems. Although they may not have all the features the users have planned, they may be used on an interim basis until the final system is delivered.In Evolutionary Prototyping, developers can focus themselves to develop parts of the system that they understand instead of working on developing a whole system.Incremental prototyping

The final product is built as separate prototypes. At the end the separate prototypes are merged in an overall design.

Extreme prototyping

Extreme Prototyping is an architectural process for developing applications, especially web applications, in terms of increasingly functional prototypes. At a high level, it breaks down web development into three distinct phases. The first phase is the static prototype, consisting of HTML pages and possibly a logical data model supporting those pages. The second phase is a coding process in your chosen web framework whereby the screens are fully functional using a simulated services layer. The third phase is where the services are implemented. The process is called Extreme Prototyping to draw attention to the second phase of the process, where a fully-functional UI is developed with very little regard to the services other than their contract. This deliverable, much like the static HTML prototype, can be considered a prototype, albeit a dynamic one.

By using Extreme Prototyping, you will be able to substantially shorten the requirement cycle and also the development cycle. Extreme Prototyping will allow you to consistently estimate and deliver your projects faster, cheaper, and better. Extreme Prototyping achieves these results primarily by breaking down the dependencies between multiple teams and thereby allowing parallel development. Extreme Prototyping continues to put extra emphasis on executable deliverables.

The Three Bricks of Extreme Prototyping

If you imagine system development as a set of concrete deliverables, you can imagine an “Extreme Prototype” to consist of three bricks, as depicted in Figure

The first

brick is the Static Prototype. Based on this prototype, the UI brick and the Service brick can be developed fairly independently and brought together toward the end of the project for an integration alignment. The service contracts (or blades) should allow for a perfect alignment in any typed language.

Source:

Information System Prototyping

Posted in Agile Software Development by
Information System Prototype

A prototype typically simulates only a few aspects of the final solution, and may be completely different from the final product.In terms of an information system, prototypes are employed to help system designers build an information system that intuitive and easy to manipulate for end users. Prototyping is an iterative process that is part of the analysis phase of the systems development life cycle.

During the requirements determination portion of the systems analysis phase, system analysts gather information about the organization’s current procedures and business processes related the proposed information system. In addition, they study the current information system, if there is one, and conduct user interviews and collect documentation. This helps the analysts develop an initial set of system requirements.

Prototyping can augment this process because it converts these basic, yet sometimes intangible, specifications into a tangible but limited working model of the desired information system. The user feedback gained from developing a physical system that the users can touch and see facilitates an evaluative response that the analyst can employ to modify existing requirements as well as developing new ones.

Dimensions of prototypes
  1. Horizontal Prototype:  A common term for a user interface prototype is the horizontal prototype. It provides a broad view of an entire system or subsystem, focusing on user interaction more than low-level system functionality, such as database access. Horizontal prototypes are useful for:
    • Confirmation of user interface requirements and system scope
    • Demonstration version of the system to obtain buy-in from the business
    •  Develop preliminary estimates of development time, cost and effort.
  2. Vertical Prototype: A vertical prototype is a more complete elaboration of a single subsystem or function. It is useful for obtaining detailed requirements for a given function, with the following benefits:
    • Refinement database design
    • Obtain information on data volumes and system interface needs, for network sizing and performance engineering
    • Clarifies complex requirements by drilling down to actual system functionality
Sources:

Delivering Outstanding Customer Care in a High Volume Call Center Environment

Posted in General by

Date of publication: 28/06/2011

After ten years of operation, the Digicel Group is one of the biggest mobile telecommunications companies in the Caribbean, Central America, and the Pacific, with 11.5 million customers across its 32 markets. Digicel is renowned for delivering the best value, best service, and best network. Its constant effort to offer an exceptional service and to revolutionize the mobile and broadband landscapes in its markets has made it grow rapidly. Microsoft Dynamics® CRM business software offered it a solution that was flexible for its business and could be quickly integrated with its existing software. With an accelerated learning curve for the end users, Microsoft Dynamics CRM helped Digicel offer what it values the most: the best customer service.

Organization Profile
Digicel Group Limited is one of the biggest mobile telecommunications companies in the Caribbean, Central America, and the Pacific. It has 11.5 million customers across its 32 markets.

Organization Size: 5500 employees.

Situation

The Digicel Group was first established in April 2001 in Jamaica, amassing 100,000 customers in their first 100 days. Today, Digicel operates in 32 markets, serving 11.5 million customers, with over 70 percent market share in Jamaica alone. Digicel has 5,500 employees, 1,000 retail stores, and offers mobile telecommunications, telecom services, WiMAX broadband, and 3G/4G broadband, among other services.

Digicel has enjoyed 10 percent subscriber growth year on year and increased its market share quarter on quarter in all of its major markets (El Salvador, Haiti, Jamaica, Papua New Guinea, and Trinidad & Tobago). In order to offer its clients first-class customer service, Digicel has made significant investments in innovation through advanced software and technologies. However, it still lacked an integrated Customer Relationship Management (CRM) solution that would help tie all systems together.

Digicel’s original CRM system consisted of in-house custom solutions with limited integration with its operational and business support systems (OSS/BSS). “It had become apparent that the rapid expansion of Digicel and explosive growth in customer numbers had now superseded the capacity of these systems,” John Riordan, Digicel Group IT Director/CIO explains. “These limitations were beginning to adversely affect the customer care operations and Digicel’s leadership position in providing top-class customer service in the region,” he continues.

Digicel needed to replace its in-house systems for its main customer care operation centers to keep up with its rapid growth. Digicel considered a variety of CRM systems, including Siebel, Clarify, and Remedy’s suite of products; however, those systems were disqualified for not meeting cost and flexibility requirements. Riordan clarifies that the alternatives were “not flexible enough for our business and lead times to readiness for production use.”

Solution

Ultimately, Digicel decided on Microsoft Dynamics® CRM for its compelling value, its ability to be quickly integrated with its existing systems, and its functional similarities with the Microsoft® Office products that it already used. “We did realize early on that Microsoft Dynamics CRM was not being used anywhere in the world in high volume call centers similar to ours,” Riordan says. Digicel recognized the risk with integrating a solution that had not been proven at this scale; nonetheless, it was confident that Microsoft had the necessary resources and expertise to assure a successful implementation. Microsoft’s regional team took advantage of Digicel’s high-volume requirements to develop the Microsoft Dynamics roadmap for high volume and contact center environments.

To ensure the project was properly delivered, Digicel worked with Microsoft Consulting Services (MCS) to architect, design, and deploy Microsoft Dynamics CRM in three of its customer care operation centers in the Caribbean and Central America. All locations are high volume call centers where 3,000 agents process over 2.5 million calls per month. The solution was quickly deployed and integrated into its environment through the use of the Microsoft Dynamics Sure Step  methodology.

The implementation of Microsoft Dynamics CRM in Digicel’s biggest customer care center took less than six months and was deployed to over 300 users processing almost one million customer calls/tickets per month. “We would rate the transition [to Dynamics CRM] as being one of the most straightforward ones for major system integration. It did not at any point require us to cease operations,” says Riordan.

Microsoft Dynamics CRM has helped to improve key measures in Digicel’s customer call centers, including a reduction in average talk time, higher call process ratio to agent, and an increase of first call resolutions. “It also enabled the automation of workflows by taking advantage of powerful APIs that were available on our operational and business support systems to integrate with the Microsoft Dynamics CRM solution,” says Riordan. The solution at Digicel evolved from its initial release with the subsequent inclusion of the Microsoft Customer Care Accelerator (CCA) for Microsoft Dynamics CRM. With the implementation of Microsoft Dynamics CRM and CCA, Digicel continues to provide the incredible customer service that distinguishes it from other mobile telecommunications companies.

We would rate the transition [to Dynamics CRM] as being one of the most straightforward ones for major system integration. It did not at any point require us to cease operations.

John Riordan
IT Director and CIO
Digicel Group

Benefits

Digicel deeply integrated Microsoft Dynamics CRM with its existing OSS/BSS. Traditional Extract/Transform/Load (ETL) processes comprised some of the effort, such as aggregating customer data from the Microsoft Dynamics CRM data store into the Digicel Data Warehouse for Business Intelligence reporting. But most of the integration was accomplished via the use of more agile Services Oriented Architecture (SOA) approaches that were made possible with the use of the Customer Care Accelerator, resulting in increased operational agility and faster integration. Additionally, the Interactive Voice Response (IVR) and Computer Telephony Interface (CTI) systems that are at the heart of the call center environment were also integrated into the Microsoft Dynamics CRM system, thus enabling agents to more efficiently service their customers.

Digicel now experiences significant benefits from using Microsoft Dynamics CRM in their main customer call center operations, including a complete 360-degree view of their internal customer information, simple yet powerful tools for their agents, and enhanced workflows to more effectively manage customer interactions. “The solution has resulted in improved analytics for the customer care centers,” says Lesline Chisholm, Digicel Jamaica’s Director of Customer Care. Some of the specific benefits obtained by using Microsoft Dynamics CRM and the Customer Care Accelerator in Digicel’s customer care centers include:

  • Significant Reductions in Average Handling Time Microsoft Dynamics CRM provided Digicel’s customer care offices with tools that simplified case management, streamlined escalations, improved knowledge sharing, and enabled more effective account management. Digicel’s customer call agents now respond to cases faster with immediate access to complete case and customer data. The solution offers guided business processes via simple dialogs to deliver fast and precise service. It also features familiar graphical tools that make it easier for the agents to respond to their customer’s needs.
  • Improved First Call Resolution Rates Microsoft Dynamics CRM helps Digicel’s customer call agents achieve operational efficiencies and improve information flow. “This solution improved aggregation of customer data and by extension improved data integrity,” says Riordan. Microsoft Dynamics CRM helps Digicel to foster greater internal collaboration and to improve work state management with its different communication tools. With Microsoft Dynamics CRM, Digicel’s agents resolve 88 percent of customers’ issues on their first call, resulting in reduced operational costs and more satisfied customers.
  • Reduced Training Time Microsoft Dynamics CRM was already familiar to Digicel’s customer call agents. “The business was already using the Microsoft Windows® desktop and the Microsoft Office® suite of products across the business,” Riordan says. Microsoft Dynamics CRM offers users the ability to manage all their email messages, meetings, contacts, and customer information in one place using the Microsoft Outlook® messaging and collaboration client.
  • Improved Employee and Customer Churn Digicel focuses on offering the best value, best service, and best network for its customers. With Microsoft Dynamics CRM, its customer call agents have become more efficient and can now process more calls in the same time, offering better and faster services to Digicel’s customers. The efficiency and ease of use provided by Microsoft Dynamics CRM have contributed to improved customer and agent job satisfaction, with a 95 percent satisfaction rate for clients attended by Digicel’s customer call agents. The reduced training time, simplified and familiar interface, and guided automated workflows greatly improve the productivity and job satisfaction of Digicel agents.
  • Improved Operations Microsoft Dynamics CRM has made customer management more efficient by improving the operational and support systems. “The application is considered mission critical because of the emphasis we put on customer care and the delivery of high quality customer services,” Chisholm says. The solution has delivered an easier way of collecting customer data and increasing their staff’s productivity, giving their subscribers the first class service they expect from Digicel.

Microsoft Dynamics CRM has helped Digicel to deliver high quality customer services and to enhance operations with a more integrated information system. Digicel and Microsoft have nurtured a good relationship through the integration of Microsoft Dynamics CRM. Riordan states that he would like to make Microsoft Dynamics CRM “the single repository for all customer transactional data.” Digicel plans to further integrate with other operational and business support systems and to provide direct online help to its customers in the near future.

View analysis of this case study

More Details:

Management Information Systems (MIS) Part-2

Posted in General by

Part-2

Read Previous:

Source of management information systems

Source of management information systems

Applications of Management Information System

With computers being as ubiquitous as they are today, there’s hardly any large business that does not rely extensively on their IT systems.
However, there are several specific fields in which MIS has become invaluable.

Strategy Support
While computers cannot create business strategies by themselves they can assist management in understanding the effects of their strategies, and help enable effective decision-making.

MIS systems can be used to transform data into information useful for decision making. Computers can provide financial statements and performance reports to assist in the planning, monitoring and implementation of strategy.

MIS systems provide a valuable function in that they can collate into coherent reports unmanageable volumes of data that would otherwise be broadly useless to decision makers. By studying these reports decision-makers can identify patterns and trends that would have remained unseen if the raw data were consulted manually.

MIS systems can also use these raw data to run simulations – hypothetical scenarios that answer a range of ‘what if’ questions regarding alterations in strategy. For instance, MIS systems can provide predictions about the effect on sales that an alteration in price would have on a product. These Decision Support Systems (DSS) enable more informed decision making within an enterprise than would be possible without MIS systems.

Data Processing
not only do MIS systems allow for the collation of vast amounts of business data, but they also provide a valuable time saving benefit to the workforce. Where in the past business information had to be manually processed for filing and analysis it can now be entered quickly and easily onto a computer by a data processor, allowing for faster decision making and quicker reflexes for the enterprise as a whole.

Types of management information systems

There are many types of management information systems in the market that provide a wide range of benefits for companies.

  • Transaction processing systems (TPS) collect and record the routine transactions of an organization. Examples of such systems are sales order entry, hotel reservations, payroll, employee record keeping, and shipping.
  • Management information systems (MIS) produce fixed, regularly scheduled reports based on data extracted and summarized from the firm’s underlying transaction processing systems (TPS) to middle and operational level managers to provide answers to structured and semi-structured decision problems.
  • Decision-support systems (DSS) are computer program applications used by middle management to compile information from a wide range of sources to solve problems and make decisions.
  • Executive support systems (ESS) is a reporting tool that provides quick access to summarized reports coming from all company levels and departments such as accounting, human resources and operations.
  • Expert system (ES) is a knowledge about a specific area to act as an expert consultant to the user. It is no the replacement of human being rather they help them in using their expertise more efficiently and effectively. When we join the concept of artificial intelligence with information system, the result is an Expert System.
  • Office automation systems (OAS) are meant for improving the communication and productivity of people in the enterprise. They attempt to automate office procedures and remove bottlenecks, lacuna in the secretarial work. These systems are helpful to all levels of management.

Benefits of Management Information System

The field of MIS can deliver a great many benefits to enterprises in every industry. Expert organizations such as the Institute of MIS along with peer reviewed journals such as MIS Quarterly continue to find and report new ways to use MIS to achieve business objectives.

Core Competencies
Every market leading enterprise will have at least one core competency – that is, a function they perform better than their competition. By building an exceptional management information system into the enterprise it is possible to push out ahead of the competition. MIS systems provide the tools necessary to gain a better understanding of the market as well as a better understanding of the enterprise itself.

Enhance Supply Chain Management
Improved reporting of business processes leads inevitably to a more streamlined production process. With better information on the production process comes the ability to improve the management of the supply chain, including everything from the sourcing of materials to the manufacturing and distribution of the finished product.

Quick Reflexes
As a corollary to improved supply chain management comes an improved ability to react to changes in the market. Better MIS systems enable an enterprise to react more quickly to their environment, enabling them to push out ahead of the competition and produce a better service and a larger piece of the pie.

Further more:

  • Increased brand equity
  • Boost production processes
  • Impact mass customization production processes
  • Leverage learning curve advantages
  • Leverage IT investment in computer aided design
  • Leverage stability
  • Expand E-commerce
  • Improve B2B commerce

Five Elements of usable MIS

  • Timeliness
  • Accuracy
  • Consistency
  • Completeness
  • Relevance

Difference between MIS and Traditional Information system

Although Management Information Systems and  Information Systems are segments of Information Technology, both are entirely diverse streams. Management Information Systems deals with the overall in-house controls of an industry covering the employees, documents, know-how, and measures adapted by administration accountants to unravel business tribulations like estimating and pricing a product, service or a business-wide strategy. However, Computer Information Systems is concerned with the integration of computers, data, software packages and management techniques to carry out the day-to-day operations of an organization.

Source:

http://en.wikipedia.org/wiki/Management_information_system
http://www.bestpricecomputers.co.uk/glossary/management-information-system.htm
http://www.ehow.com/about_5180850_principles-management-information-systems.html
http://blog.maia-intelligence.com/2008/04/08/management-information-systems-mis/
http://entrance-exam.net/difference-between-management-information-systems-and-computer-information-systems/