IDE - Intercompany Data Exchange:
Before deregulation of utilities sector, the companies were used to be vertically Integrated having �bundled� businesses (i.e. Generation, Transmission, and Distribution) under a tightly integrated holding company/operating company model. Hence all data from all parts of the value chain were accessible to all parts of the company.

But after deregulation, companies are now split into individually operating, self accounting units for generation, transmission, distribution, and supply. So, data that was previously contained in a single system is now distributed amongst the different operating units in the value chain. In order to obtain all data needed to complete processing, companies must share data between systems.

IDE, an add-on to SAP IS-U/CCS provides a mechanism to effectively exchange and control data between service providers’ systems. Actual transfer of data is done through Standard SAP’s EDI / IDOC communication and hence in a sense IDE is a layer above EDI/IDoc functionality. IDE covers the areas below:

Administration of deregulation data:
It includes PoD, Grids, Point of delivery Services and Service Providers.

Process Execution - Communication Control
To send and receive data for certain events. It uses PoD to determine the sender, receiver and the information to be sent along with the required format.

Management of Data Exchange Processes

Customer Service:
This component provides centralized and easy access to customer data, through one screen, called Customer Interaction Center(CIC) or Front Office. By using CIC / Front Office, Customer service operator can also start the frequently used business processes at the request of customer.

These processes, called a workflow, are generally a sequence of activities with dependencies and are performed by several people.
e.g. A request by the customer for a new connection will require a series of steps like creation of business & technical master data and then execution of move-in to create a contract.

Further, this will be a lot more complex in case of a change of supplier ( not a new connection ) as a lot of data exchange between the service providers ( winner & looser suppliers) and Transmission Company is required.

Along with standard SAP R/3, SAP has provided solutions that cater to the special demands of a particular Industry and are seamlessly integrated with the components of standard SAP. e.g. A equipment defined in standard SAP R/3 PM can be used while creating a device in SAP IS-U. These are called Industry Specific solutions.
SAP IS-U/CCS stands for the Industry Specific Solution for Utilities - Customer Care & Service

SAP IS-U/CCS component is a Sales & Information system that supports all business processes and utility services of a utility company.
Processes related with divisions of a Utility Company e.g. Electricity, Gas, Water, Heating, Waste Disposal can be handled by SAP IS-U.

The core IS-U/CCS application is a consumption billing system that valuates measured and flat rate consumption and services. Though Services ( but not consumption ) can also be billed and invoiced using standard Sales & Distribution (SD).
In a utility company, given the size of data processing, Billing is probably the most challenging and important area for any ERP system considering the processing required for millions of customers every month-end.

Not every SAP / ERP implementation is as successful as it should have been. Also because every project and every company used to have its own challenges. Further, the approach that work for one scenario, may not work in other. However, we can still learn a lot from past experiences, gained in a similar scenario.
Generally, the approach, processes, tools and methodologies, which has evolved and has been quite successful over a period of time, for a given scenario, are collectively called as Industry Best Practices. Industry Best Practices for different industry types (e.g. Manufacturing, Utilities etc. ) has also evolved and made available for SAP projects.

Most of the companies follow these practices while implementing or running SAP systems and that helps in avoiding project failures. It also reduces implementation / running cost, total cost of ownership and ensures better ROI ( Return on Investment ).

Here are a few links on web which provides detail of a few real life SAP projects, its challenges, Project Management, Risk Management, methodologies, execution, results and lessons learnt etc, simply called as SAP Case Study.

Web-Links for SAP Case Studies:

SAP Netweaver Case Studies @sap.com
SAP Netweaver Case Studies at www.sap.com
http://www.sap.com/platform/netweaver/customersuccess/idc.epx

BPCL SAP Case Study and Analysis
Check out this web page of IIMA - Prof. Arabinda Tripathy regarding BPCL SAP Implementation Case Study and analysis
http://www.iimahd.ernet.in/~tripathy/

Six Degrees of Success or Failure in ERP Requirements Engineering
Six Degrees of Success or Failure in ERP Requirements Engineering: Experiences with the ASAP Process By Maya Daneva
http://www-rcf.usc.edu/~anthonyb/itp320/ASAP.ppt

Failure of HP’s SAP roll-out : A case study
When Bad Things Happen to Good Projects: BY CHRISTOPHER KOCH
http://www.cio.com/archive/120104/contingencyplan.html

ERP a savior or slayer of enterprise competitiveness
Institute of International Management - University of Lausanne
http://www.hec.unil.ch/iumi/iumi/WP/0305.doc

The V-model is an internationally recognized development standard for IT systems which uniformly and bindingly lays down what has to be done[Procedure], how the tasks are to be performed[Methods] and what is to be used to carry this out[Tools].
3 Levels of V-Model:
The standardization concept of the German Federal Authorities pursues this objective by regulations on three levels:
Software Lifecycle Process Model.
Methods to be used.
Tool Requirements.

Submodels of V-Model:
The V-Model is structured into functional parts, called submodels. These four submodels are closely integrated and mutually influence one another by exchange of products/results. These submodels are as below:
Project management (PM): plans, controls and informs the SD, QA and CM submodels.
Software/System development (SD): develops the system or the software.
Quality Assurance (QA): specifies quality requirements, test cases and criteria, and examines the products and the compliance with the standards.
Configuration Management (CM): administrates the products generated.
Software Development Submodel - [ Also known as the traditional V-Model ]

Conventional V-Model represents the development process in the form of a V shape. The right side of the V represents the testing where the systems is validated against the specifications defined on the left side. The meeting point of the V represents the actual development.
Use of V-Model in ABAP Development Lifecycle:
Generally in implementation Projects, ABAP development cycle will be somewhat :
Requirement Analysis

Application Design - High Level design - quite functional - contains functional test cases or guidelines for test cases - Review of AD - Review comments implemented till sign off by the stake holders ( client side / consultant side )

Detail Design Detail Level design - quite technical as well - Man-hours required is estimated and mentioned - contains functional & technical unit test cases - Review of DD - Review comments implemented till sign off by the stake holders ( client side / consultant side )

Development - Coding by the developers as per the detail design -

Unit Testing - is done in Development Server by the developer to ensure that program works as per the detail design - add / implement test case results - transport request details & documentation in detail design - Evidence is attached. Code Review to ensure that coding is as per the coding standards ( performance related as well ) - Also check the test cases and verify - Review comments implemented till sign-off by the stake holders. Before Application testing the realted chunk of work is transported to QA Server.

Application Testing / Integration Testing - This is to ensure that programs work along with other components, that might get affected. e.g. Even the Invoice process should be tested if a change is made in the interface related with a PO creation / change. The test cases or created separately ( more functional in nature and considers dependency of components ). Before implementation of the release, the complete product needs to be tested to ensure that it can bear the maximum load of a production environment.

Product Testing / Load Testing - is performed with huge datasets to check if system / product can handle production scenario in terms of memory and performance.

Final Implementation in Production.

Support - Any further problems will be solved as Bug-fix or and enhancments will be carried out as a part of change request.

AcceleratedSAP methodology is proven, repeatable and successful approach to implement SAP solutions across industries and customer environments.
It provides content, tools and expertise from thousands of successful implementations.

Phase 1: Project Preparation :

During this phase the team goes through initial planning and preparation for SAP project.

Define project goals and objectives
Clarify the scope of implementation
Define project schedule, budget plan, and implementation sequence
Establish the project organization and relevant committees and assign resources

Phase 2: Business Blueprint

The purpose of this phase is to achieve a common understanding of how the company intends to run SAP to support their business. Also, to refine the original project goals and objectives and revise the overall project schedule in this phase. The result is the Business Blueprint, a detailed documentation of the results gathered during requirements workshops.

Phase 3: Realization:

The purpose of this phase is to implement all the business process requirements based on the Business Blueprint. The system configuration methodology is provided in two work packages: Baseline (major scope); and Final configuration (remaining scope). Other key focal areas of this phase are conducting integration tests and drawing up end user documentation.

Phase 4: Final Preparation:

The purpose of this phase is to complete the final preparation (including testing, end user training, system management and cutover activities) to finalize your readiness to go live. The Final Preparation phase also serves to resolve all critical open issues. On successful completion of this phase, you are ready to run your business in your live SAP System.

Phase 5: Go Live & Support:

The purpose of this phase is to move from a project-oriented, pre-production environment to live production operation. The most important elements include setting up production support, monitoring system transactions, and optimizing overall system performance.

Device Management:
This component manages the installations, meter reading, and the certification of all devices for a utility company. Devices can be a electric meter or Gas meter etc.
Device Management of SAP IS-U is integrated with SAP PM ( Plant Maintenance ). Device is an instrument to measure consumption, processing data or controlling and protecting other instruments. Devices are identified using material and srl number and are managed in PM as pieces of equipment with serial numbers.

Billing:
This component is used for billing the standard divisions like electricity, gas, water / waste water, district heating, and multimedia services( e.g. Cable TV )
SAP IS-U billing is integrated with FI-CA, Accounts Receivable & Payable and it manages postings from billing and budget billing requests.

Invoicing:
SAP IS-U Invoicing enables grouping of bills before sending it to customer. Also, it handles extra fee / tax charging requirements.
e.g. If one customer is taking services from both the divisions, electricity as well Gas or has multiple contracts, then as per the requirement, bills can be grouped into one invoice.