BusinessIntelligenceProject ImplementationAndManagement DosandDontswithBestPractices

BUSINESSINTELLIGENCEPROJECTIMPLEMENTATION&MANAGEMENT

DOSANDDONTSWITHBESTPRACTICES

Author:ChaitanyaBhure ServiceOffering(s):Consulting

PublishDate:15October2010

Chaitanya Bhure

Table of Contents
1.0 EXECUTIVESUMMARY 5 7 7 10 10 11 12 15 16 17 18 19 21 21 23 25 27 27 28 28 29 30 30 31 31 31 31 32 32 33 33 33 2.0 REQUIREMENTGATHERINGANDANALYSIS 2.1 SystemRequirementStudy/BusinessRequirementStudy 3.0 DESIGNPHASE 3.1 ReportRationalizationDocument(RRD) 3.2 ReportDefinitionDocument(RDD) 3.3 UniverseDefinitionDocument(UDD) 3.4 LogicalDataModel(LDM) 3.5 MappingDesignDocument 3.6 ReportSchedulingSpecification 4.0 DEVELOPMENTPHASE 4.1 ETLDevelopment 4.2 UniverseandReport/DashboardDevelopment 4.2.1 UniverseDevelopment 4.2.2 WebiReportDevelopment 4.2.3 DashboardsDevelopment 4.3 UnitandSystemIntegrationTesting 4.3.1 ETLTesting 4.3.2 ReportTesting 5.0 DEPLOYPHASE 5.1 PerformUATonDevelopmentenvironment 5.2 UserTraining 5.3 PreparetheBODSXI3.1ProductionEnvironment 5.4 PreparetheBOXI3.1ProductionEnvironment 5.5 MigrationofDevelopmenttoProduction 5.5.1 ETLMigration 5.5.2 ReportMigration 5.6 ReviewandValidation 6.0 EVOLVEPHASE 6.1 KnowledgeSharing 6.2 PostProductionSupport 6.3 Exclusions

Chaitanya Bhure

7.0 PROJECTORGANIZATION 7.1 VendorsRolesandResponsibilities 7.2 CustomersRolesandResponsibilities 7.2.1 CustomerResponsibility: 8.0 DELIVERABLESANDACCEPTANCECRITERIA 8.1 Deliverables 8.2 AcceptanceProcedureandCriteria 8.3 SignofftheUserAcceptanceTest(UAT) 8.4 RequirementChanges 8.4.1 ChangeControlProcess 8.4.2 ResponsetoRequestforChange 8.4.3 CustomerApproval 8.4.4 Implementation 9.0 PROJECTCOMMUNICATION&CONTROLMECHANISMS 9.1 HowdoesonedoBasicLevelBIProjectManagement? 10.0 RISKMANAGEMENT

33 34 37 38 39 39 39 40 41 41 42 42 42 43 44 47

Chaitanya Bhure

1.0 EXECUTIVESUMMARY
This document details about the learnings of one of the major fixed bid Business Intelligence Project Implementation for one of the major FMCG player from the Indian Market. This type of major implementation requires careful monitoring process and clear definition of milestones. Reaching a milestone at the prescribed deadlines requires the milestones to be broken into various tasks and the resourcesthataregoingtocompletethosetasks. For tracking the completion of various tasks and reaching a milestones on said deadline requires a Project Management tool like MS Office Project Professional Edition which gives various analysis like which task missed the deadline and why. This will avoid the project delay and dispute with customer. These tools will also ensure proper change control mechanism if client suggests some changes which needstobeincorporatedintheprojectplanandnewdeliveryscheduleisagreeduponwithcustomer. In the design phase tools like ERWIN should be used instead of Excel for EntityRelationship Diagram (E R)whichalsoensuresreductioninmanualworkanddelay. While implementing the above BI project, manual monitoring was done instead of proper project management tool which was time consuming with no proper analysis of tasks and milestones achievement. This resulted into dispute and delay with both the vendor and client companies blaming each other for delay. Proper change control mechanism also could not be ensured because the process was all manual and a lot of time was wasted in estimation of efforts and convincing client about the change. It should also be noted that before you submit the proposal for such large BI implementation project, proper system study should be undertaken so as to properly estimate the efforts and commercials. If customer ask to give them the proposal within short span, the vendor company should convince customer for system study which will help in avoiding future issues on project commercials, efforts, deliveryandnumberofrequirements. Duetoeverchanginginformationneedsofanorganizationrangingfromreportingtobusinessmodeling, and the data modeling, design keeps on changing. If we need to have the information management relatedtoanewsetofdataelements,theentirechainofBImaybeimpacted.Thiswilltranscendacross sourcesystemmapping,ETL,datawarehousemodeling,OLAPmodelingandmetadataupdation.

Chaitanya Bhure

 There can be number of issues which can result into delay and affect project profitability. Some of the majorissuesarelistedbelowwhichareelaboratedinmultiplesectionsofthisdocument. EffortsandCommercialEstimationwithoutproperSystemStudy Endrequirementchanges RequirementLogicchange RDDwithoutproperlogicforsomereports DataTransformationLogicchange HistoricalDataLoad Quality&ConsistencyofData SourceConnectivityIssues(SAP) SharedFoldersPermissionIssues DiskSpaceIssuesrelatedtoTargetDataWarehouse ExcelSourceIssues(PathPermission,Formats&Data) DelayduetoUserUAT DelayduetoInputsfromUserrequiredforoutput NousageofProjectManagementTool DelayduetomultipletrainingsessionsonBItoolforbusinessusers LackofcommitmentfromUsercommunity(ResistancetoChange) Frequentresourcechangedeployedonproject

Chaitanya Bhure

2.0 REQUIREMENTGATHERINGANDANALYSIS
Analyze the existing systems and the requirement of the Customer that will help in driving the Business Intelligence Solution implementation in detail, and use those requirements to guidetheanalysisofthereporting,infrastructure,dataanduserinterfacerequirements. Customershallprovidenecessarysupportandinformationrequiredinordertocomplete thetasksspecifiedinthescope.

2.1 System Requirement Study / Business Requirement Study

Dos
This document is prepared after understanding Business Requirements that are driving the wholeproject.Usetheserequirementstorecommendtheinfrastructurearchitecture. UnderstandtheexistingBusinessandterminologies Understand and review the Reporting requirements by studying the existing reports createdbytheCustomerandunderstandingofrelatedDimensionsandMeasures. Understandtheexistingdatasources. Understand the various crucial parameters defined by studying the existing reports generatedwhicharealreadyprovidedbytheCustomer. AnalysisofDatabaseSourceStructureandsourcetotablemappings. Whattypesofinformationmustyougatherinthepreliminarysurvey?Ataminimum,obtain generalinformationonthefollowingfromeachgroupofusers: Askveryspecificquestionsratherthanhighlevel. Missionandfunctionsofeachusergroup Computersystemsusedbythegroup Keyperformanceindicators Factorsaffectingsuccessoftheusergroup Whothecustomersareandhowtheyareclassified Typesofdatatrackedforthecustomers,individuallyandgroups Productsmanufacturedorsold

Chaitanya Bhure

Categorizationofproductsandservices Locationswherebusinessisconducted Levelsatwhichprofitsaremeasuredpercustomer,perproduct,perdistrict Levelsofcostdetailsandrevenue Currentqueriesandreportsforstrategicinformation The vendors primary goal in the requirements definition phase is to compile information packages for all the subjects for the data warehouse. Once firmed up the information packages,theimplementingvendorwillbeabletoproceedtotheotherphases. Essentially,informationpackagesenableimplementingvendorto: FindouttheDataSourcesfortheDataWarehousedata. Definethecommonsubjectareas Designkeybusinessmetrics Decidehowdatamustbepresented Determinehowuserswillaggregateorrollup Decidethedataquantityfortheuseranalysisorquery(HistoricalData) Decidehowdatawillbeaccessed Establishdatagranularity Estimatedatawarehousesize Determinethefrequencyfordatarefreshing Ascertainhowinformationmustbepackaged Getalistofreportsthatissupposedtocomeoutofthenewdatawarehouse. At the conclusion of this phase, the complete understanding of the systems and mapping fromthesourcesystemswillbedone. CostAdherence: There are various elements of cost linked to BI/DW projects. Cost mentioned here is the project related cost which needs to be considered in this phase of project and proper cost justification needs to be given to customer. Take all the points into consideration while arrivingatprojectcommercials.Thepointsaregivenbelow: LicenseCost(BusinessObjectsCostiflicensesarenotpurchased) Hardwarecost(VendorisnothavingtherequisitehardwareforBI) ProjectManagementCost Scopingandanalysiscost Modelingcost DesignandDevelopmentcost

Chaitanya Bhure

 Testingandimplementationcost EmployeesChargedtime Others The cost management is an important piece for BI project implementation with license and toolscostbeingonlyasmallerpiece.

Donts
Going overbroad in capturing the requirements. This should be avoided since you aregoingtodocumentit.Understandingofreportingrequirementsandfeasibilityof delivering those reports to the end customer by doing proper source system study helps in setting the expectations right and also helps in estimating the development effortsandcommercialsoftheproject. Documenting the requirements where you have doubts about data availability, tool constraintsetc.Avoidthissincethisdocumentbecomestheguidingprincipleforthe projectdevelopmentwherecustomersignoffisrequired. Non ascertaining data quantity for the user analysis (Historical Data) in this stage. Ascertain the data quantity in this stage itself and inform the customer that if historical data is for multiple years then it needs to be consistent and clean and the vendorisnotresponsibleforcleansingandconsistentdataasitisaseparateactivity itself which needs to be estimated for efforts and commercials avoiding future disputeanddelay.

Summary

Requirement analysis and gathering is a bit tough as client might not be clear with his/her requirements. Its implementation vendor expertise in the design process and prior experience which help to analyze the requirements and put it on paper. Once everything is clearmakesuretogetasignofffromtheclientontherequirementstoavoiddispute.

Chaitanya Bhure

3.0 DESIGNPHASE
The requirements identified in the previous phase are further analyzed to produce detailed design specifications for the architecture, user interface, reports, data model. A detailed Test Plan is produced in conjunction with the design specifications, which outlines unit, system, and user acceptance test scenarios.

3.1

Report Rationalization Document (RRD)

There are requirements provided by the end users to the implementing Vendor by the Customer during the business requirement meetings. Each of these requirements have been documented and approved by the end users. The purpose of a rationalization activity is to further get a detailed understanding on the business logic of each of the requirements and suggest to the end users based on past experience and expertise, as to which reports or requirements are similar in nature and which are too huge to be accommodated into one BI dashboard / report. An exercise of rationalization will enable the implementing Vendor to proceed with the design phase of the project and also help the end users meet the informational requirements with minimum number of BI reports / dashboards to be referred to.

Methodology

Chaitanya Bhure

10

The Rationalization activity will be initiated by the implementing Vendor and the following methodology will be followed throughout the process to arrive at a conclusion on the number of reports and dashboards to be developed for each department The implementing Vendor will create a matrix containing the data elements required in each and every requirement given by the respective departments Based on the data elements so captured, the team will arrive at a conclusion whether certain reports are to be merged to provide more information in a single document or needs to be split to be able to make the requirement more readable and user friendly Once the activity is completed along with an explanation of the reason for report splitting and merging, the same information will be shared with the business users for their approval Once approved, the implementing Vendor will then proceed ahead to initiate the creation of the Report Definition Document which will contain the necessary information about every rationalized requirement in terms of type of tabular data, user actions, graphs, hierarchies, drills, slice and dice and so on The implementing Vendor will also create patterns of reports and link the Report Definition Documents to the respective patterns so that the end users are able to visualize the type of report that will be developed Lastly, the requirements, design and the definition of the requirements will be fixed and developed accordingly by the implementing Vendor. Sample LDM is attached below

PA_Technical_RRD_B _V_1.1.doc

3.2

Report Definition Document (RDD)

Dos
Before starting the Implementation of Data Warehouse, we need to understand the business requirements clearly from the user in terms of how exactly the business user community see their reports at the end of the day.

Chaitanya Bhure

11

The next step is to understand the Business logic with the functional people. The business logic should be properly documented for each and every requirement (reports/dashboard) and sign off should be taken. Once through with user requirements and business logic of those requirements the next step is creating the Report Definition Document (RDD) and thoroughly checking whether all the elements are captured or not according to the discussion. The Report Definition Document will reflect the no of requirements (Reports and Dashboard) for which the implementing vendor will provide the development efforts and commercials. Taking the Sign off of RDD from the business user. Any changes coming while system development which is not captured in signed off RDD will be a Change Request and should be dealt with change control mechanism. If business user insists on change which is important to him and not captured in requirement gathering should be taken as change request and development and commercial efforts should be estimated with proper escalation to project owner from customer side. Once the change request is approved then it should be incorporated in project plan and project delivery schedule should be updated with new timelines and milestones.

Donts
After taking the sign off on RDD, allowing addition in the number of requirements (Reports and Dashboard). This should not be allowed as it will have commercial implication as it is going to extent the project delivery. Any additional requirement should be treated as change request.

Sample LDM is attached below

PA_Technical_RDD_B _V_1.0.doc

3.3

Universe Definition Document (UDD)

A universe is a semantic layer or in more familiar terms a data abstraction layer which is built with the Business Objects Designer tool. This semantic
Chaitanya Bhure

12

layer is where you define your business objects which are essentially encapsulated snippets of SQL that when properly built express a leggo like bit of business logic that can be presented in the reporting tool or through an application be used and reused to build reports. The genius of this is that this data abstraction layer sits between the database and your reports or application. This means that even if the database structure changes that instead of being required to change what could be hundreds or even thousands of reports throughout an organization to accommodate the change you instead make the changes in the universe and those changes are automatically passed through to all the reports. This has numerous benefits one being that it allows a much more flexible environment for preparing for and facilitating change in an organization. Prepare and Analyze Before you touch the Universe Designer Well, in most of the BI projects the developers make this mistake and they jump directly on designer. But this might end up in future Universe Maintenance problems. Understanding the data source on top which universe to be developed is very important. The Universe designer must understand the tables, type of data stored in those tables, relationship between tables, Business terms and their meaning, any specific formula which will be used to derive the measures. Understand Reporting need and what all tables are required to feed the data to reports.

Plan the Universe. Before you actually start building the Universe, plan it well in advance. Identify number of universes required for reporting. Identify measures, dimensions and details objects. Try to document it well and in detail. This would be a Universe blueprint which is called Universe Definition Document and which will help while actually designing the universe. Implementation or Actual Design of Universe. Once you have completed first two stages, start building the universe using Universe designer. The planning Universe Definition Document created in planning stage will help you a lot while building the

Chaitanya Bhure

13

universe. While building the universe its always better to create a Unit Testing document for universe and create unit tests for every object you create in universe. Test each and every object in universe as soon as you create it. This will minimize the possible errors and bugs. Frequently use the universe integrity test tool to identify SQL traps, join path problems. Test once its built. This is one of the very important stage of Universe building process. Have very detailed universe testing plan ready for this stage. Test universe against different scenarios, for SQL traps by creating sample reports, test measures, compare the data against manual SQL data. If possible ask few business users to use the universe for creating some sample ad hoc reports. Deploy it. Once all above stages are completed and well documented, its time to deploy it for actual use for creating reports. You can deploy universe using BIAR tool. If production Business Objects Server is available you can directly export the universe to production servers from development server.

Chaitanya Bhure

14

Maintenance. Since nothing is prefect issues are supposed to come frequently after deployment. Change the Universe for possible resolution and re deploy it. Make sure you document every change you made in universe against the change request.

3.4

Logical Data Model (LDM)

Once RDD is finalized identify the Entities, Attributes and the Grain level. Design the Entity Relationship Diagram (E R) by giving the appropriate relations of the tables. For this we can use ERWIN Tool but currently we have designed it in the Excel Sheet which is again time consuming and requires regular updates manually. Based on this we will start to design the Dimension tables by capturing all the elements by maintaining hierarchies which are used for Reporting purpose useful for business users to analyze at the lower level. Next step is to design the Fact tables by maintaining the key relationship from Dimension tables. For doing the above LDM we have developed an Excel sheet with prescribed format.

Dos
The data types which coming from the source tables have to have the following nomenclature which we will be implementing for the target database as shown below. Also for every column in the target table which we design have to follow the given below column prefix.
SNO 1 2 3 4 5 6 7 8 9 10 11 NATIVE TYPE CHAR NUMC DATS TIMS CUKY CURR QUAN UNIT DEC LANG CLNT SQL TYPE VARCHAR NUMERIC DATETIME VARCHAR NUMERIC NUMERIC VARCHAR NUMERIC VARCHAR VARCHAR COL PREFIX chv_ num_ dt_ cid_ amt_ qty_ uom_ int_ lid_ clt_

Chaitanya Bhure

15

 Donts
Once the LDM is created the users (Business / Technical) are given permission to change the structure of the target tables with the given nomenclature mentioned above. It should not be allowed. If the users change the structure then it will have the impact on the Universe and Reports which can result into project delay and project commercials and should be taken as change request with the requisite commercials.

Sample LDM is attached below

LDM_V1_0.xls

3.5

Mapping Design Document

Creating the Mapping Design Document in excel sheet where the given below details are elaborated. 1) SourceDefinition(Whereitisexactlycomingfromi.e.sourcedatabasename, sourcetables,whichserveretc 2) Transformations(Whichtransformationhastobeusedtoloadthedatainto targettablesandwhatwasthelogictoimplementtheETLflow) 3) TargetDefinition(Wherewehavetoloadthetransformeddatai.e.target databasename,targettables,whichserveretc) Once the above process is completed by designing in the Excel sheet, its been given to the development team for the Data Warehouse Implementation. The Excel sheet which is prepared is called the Mapping Design Document which is also submitted to the technical users for checking the business logic and once it is approved, it should be given sign off by the respective users. Once the Development is over, ETL Unit Testing has to be done.

Chaitanya Bhure

16

Dos
Source related Inputs (Server Name, User Name / Password, Source Database Name, Permissions) has to be given by the customer. Transformation Logic needs to be finalized by the customer. User Name / Password changes by the customer at the source level should be immediately intimated to the implementing vendor, so as to modify the credentials at the ETL level by the developer.

Donts
Once the ETL mapping is finished and approved by the customer accepting changes from the customer end in terms of adding source tables, adding columns, changing the business logic to existing mappings. This should not be allowed since it will impact the project delivery. If user insists on change it should be taken as change request and change control mechanism should be followed.

Sample LDM is attached below

Source_Target_Map ping_V.1.0.xls

3.6

Report Scheduling Specification

SchedulingReportsinWebIntelligence As per the requirements from the business users the reports can schedule daily, weekly, monthly etc or the users might refresh the report on their own. Below arethegivenschedulingstepsneededtobefollowed.

Chaitanya Bhure

17

Before scheduling the reports logon to central management console. Click on central management console. Click on servers. Click on web intelligence job server to configure. Click on destination tab. Check on unmanaged disk and click on enable button on the right. Click ok to enable the selected item. Go back to central management console and re start the web intelligence job server. Open the report to be schedule. Click on schedule option in the report. Select the format as Adobe Acrobat. Expand the destination option Uncheck use the job server Default Give the destination location for the file. E.g. D:\\Scheduled. Click on schedule button below right to run the job.

4.0 DEVELOPMENTPHASE
The specifications completed during the Design phase are used to install and configure the architecture, access the data, develop the user interface and create the reports. The Build phase is where the system is configured to fulfill the requirements defined in the previous phases.

Chaitanya Bhure

18

4.1 ETL Development

The Business Intelligence project where data warehouse development is integral part, the initial requirement gathering should be precise and exhaustive, since the ETL function in a data warehouse are most important, challenging, time consuming and labour intensive which determines the project profitability. Data extraction is complex because of the disparate source systems; data transformation is difficult because of the wide range of tasks; data loading is challenging because of volume of data. The given below are the ETL steps: BasedonLDM,creationofPhysicalDataModeltakesplacewhichmeansdetermineall thetargetdataneededinthedatawarehouse. LoadingMasterTables:LoadingandgroupingdataintoMastertables CreatingStagingAreawhichwillhaveTransformation,AggregationandLoadingasper BusinessRequirement. CreatingTargetAreawhichwillhaveTransformationandLoadingasaprocess Thedataloadingfunctionrelatestotheinitialload,regularperiodicincrementalloads andfullrefreshesfromtimetotime.

Dos
Thecomponentsofthedimensionalmodelarederivedfromtheinformationpackages intherequirementsdefinition(SystemStudy) Theentityrelationshipmodelingtechniqueisnotsuitablefordatawarehouses;the dimensionalmodelingtechniqueisappropriate TheSTARschemausedfordatadesignisarelationalmodelconsistingoffactand dimensiontables. Thefacttablescontainthebusinessmetricsormeasurements;thedimensionaltables containthebusinessdimensions.Hierarchieswithineachdimensiontablesareusedfor drillingdowntolowerlevelsofdata. STARschemaadvantageis:easyforuserstounderstand,optimizesnavigation,most suitableforqueryprocessing,andenablesspecificperformanceschemes. Slowlychangingdimensionsmaybeclassifiedintothreedifferenttypesbasedonthe natureofthechanges.Type1relatestocorrections,Type2topreservationofhistory andType3tosoftrevisions.Applyingeachtypeofrevisiontothedatawarehouseis different. Largedimensiontablessuchascustomerorproductneedspecialconsiderationsfor applyingoptimizingtechniques. Aggregateorsummarytablesimproveperformance.Formulateastrategyforbuilding aggregatetables.

Chaitanya Bhure

19

 Whiledevelopmentifdevelopmentteamscomeacrosscertainproductlimitationthenit shouldbeimmediatelycommunicatedwiththetechnicaluserofthecustomerand decisionneedtobetakenwithmutualconsiderationespeciallywiththeclustertablesin SAP. Ifthereisproblemindataextractionfromsourcesystemlikeextractionofdatafrom purchaseregisteredtablesofSAPthenZtablecanbeprovidedbythecustomerwhich theETLteampicksassourceandpushthedatatotargetdatabase.Thescheduleto updatetheZtableisentirelycustomerresponsibilityagainstwhichourETLjobsare schedulewhichshouldbenotifiedtothecustomerinsuchsituations. Ifhistoricaldataispartofsuchprojectthenitisdutyofcustomertoprovidecleanand consistentdataandvendorwouldnotberesponsibleforanydataqualityor consistencyissues.Itshouldbeinformedtocustomerpriortoimplementingthe projectandproperexpectationsneedstoset. Ifthesourceisexcelthenvendorshallstandardizedthoseexcelsheetsandsubmitit totheuserfordatapopulationintheprescribedformatonly.Usersshouldbe intimatednottochangetheformatwhilepopulatingtheexcelsheet.Ifusereven afterrepeatedcommunicationalterstheformatofstandardizedexcelsheetwhichcan resultintoprojectdelayduetoerrorinETLload.Suchinstancesshouldberecorded andnotifytotheProjectOwner(Customer)forpossiblecommercialimplications. KeepbufferforactivitieslikeETL:ETL(extraction,transformation,loading)isthemost complexworkoneneedstodointheDataWarehouse.Oneshouldplaymore realistic,whenestimatingthetimeforETL.

Donts
SnowflakingorcreatingasnowflakeschemaisamethodofnormalizingtheSTAR schema.Althoughsomeconditionsjustifythesnowflakeschema,itisgenerallynot recommended. Miscellaneousflagsandtextualdataarethrowntogetherinonetablecalledajunk dimensiontable. ChangingbusinesslogicduringtheETLdevelopmentforanybusinessareawhichis completedandthereportingdevelopershavealreadydevelopeduniverseandreports /dashboards.Iftheusersinsistsonchangesinthebusinesslogic(ETLFlow)the vendorshouldbeconsideringitasamajorchangerequestandappropriateeffortsand commercialsneedtobeestimatedsincethiswilldelaytheprojectandaffectthe projectprofitability. Includingdataqualityscopeinsuchtypeofprojectsevencriticalfromcustomerpoint ofview.Dataqualityproblemsrunthegamutofdummyvalues,missingvalues, crypticvalues,contradictingvalues,businessruleviolations,andinconsistentvalues andsoon.Dataqualityisprojectinitselfandpropercustomerexpectationshouldbe donepriortobiddingforsuchprojects.

Chaitanya Bhure

20

4.2 Universe and Report / Dashboard Development 4.2.1

Dos
DevelopmentofSemanticLayer(Universe(s))aspertheSRS,RDDandUDDDocuments.

Universe Development

Developmentofreportsasperthebusinessrequirement. WhiledevelopingtheUniverseloginID,password,connectionstringtothedatabase anddatabasenametobeprovidedbeforedevelopment. RelationshipbetweenfactsanddimensionaltablesshouldbecapturedinaUDDwhich thedevelopmentteamcanuseintheuniversedevelopmentandwhichwasnot implementedinthecurrentproject. Whileuniversedevelopmentunderstandingthetablesandtheirnames,their relationship(Joins),definingjoins,contextandresolvingtheloopsaremajoractivities. Forclassesandobjectsthebusinessnamesshouldbedefineinconcurrencewiththe businessusers ObjectsdescriptionneedtobecapturedintheRDD ProperUniverseversioningneedtobemaintained. Universebackup(biarfile)needtobetakeneverydayasbestpracticeincaseofany untowardincidentlikeserverproblem/crashetc Propernetworkconnectionistheresponsibilityofthecustomerforsmooth development.

Donts
ForgettingtotaketheusersignoffoncetheUniversedevelopmentforaparticular departmentiscompleted.Takethesignoffsototaketheconcurrenceonbusiness namesandrelationshipbetweentablesfromthebusinessuserswhichwasnotpractice inthecurrentproject. ForgettingtoprovidethesamplereportsdevelopedontheUniversewhichcompleted fromdevelopmentperspective.Samplereportsneedtobeprovidedtotheuserfor testingtheuniversewhichwasnotapracticeinthecurrentprojecttotakethe concurrenceonreportresults. Changingtablestructuredevelopedintargetdatabasewhiledoingdatamodeling shouldbeavoidedasitwillhaveamajorimpactontheUniverseandreportsalready developedresultingintoprojectdelay.

UniverseDevelopmentGuidelinesandBestPractices
Gives the basic guidelines/practices that could be followed in any Universe Design

Chaitanya Bhure

21

Connection
Whenusingarepository,alwaysdefineaSECUREDConnectiontotheDatabase. UsetheUniversePropertypaneltodefinetheUniverseUseandVersion(last update). DefinetheConnectionNamethathelpsforEasyDatabaseIdentification.

Class
DefineUniverseClasses/Subclassesasperthebusinesslogic&NamingConvention. AVOIDAutoClassgenerationintheDesigner. GivedescriptionfortheuseofeachClass/SubClass. Avoiddeeplevelofsubclassesasitreducesthenavigabilityandusability.

Objects
ObjecttobeusedincalculationHAStobeMeasureObjects. ObjecttobeusedinAnalysisHAStobeDimensionObjects. GivedescriptionfortheuseofeachObject. IncludeanEg.inthedescriptionforObjectsusedinLOV. DonotsetLOVOptionforeachDimension.UseitonlyforrequiredObjects,esp. thosetobeusedinReportPrompts. Keep"AutomaticRefreshbeforeUse"optionclickedforLOVObjects IfLOViseditablebytheuser,provideasignificantnametoListNameunderobject properties. Allthemeasureobjectsshoulduseaggregatefunctions. AvoidhavingduplicateObjectnames(indifferentclasses).

Predefined Conditions
Givedescriptionfortheuseofeachpredefinedcondition. Ifconditionisresultinginaprompt,makesureassociatedDimensionObjecthasLOV.

Tables
AliasTablesshouldbenamedwithproperfunctionaluse.

Chaitanya Bhure

22

ArrangethetablesintheStructureasperBusiness/Functionallogic.Thishelpsother Universeusersinunderstanding.

Joins & Context

AVOIDkeepinghanging(notjoined)tablesinthestructure. AVOIDhavingjoinsthatarenotpartofanycontext. Giveproperfunctionalnamingtothecontextforeasyidentification. AVOIDhavingN:Njoins.

Import/Export
MakesureofthepathforImport,whichusuallyisalwaysintheBusinessObjects' Universefolder. LOCKtheuniverseifAdministrator/Designerdoesnotwantanyuserto Import/Export. DO"IntegrityCheck"beforeExportingtheUniverse. Goodtohavecorrectfolderstructure,sothatyoucanhaveasecuredenvironment. Migration Bettertakeabackupoftherepositoryandthenproceedwiththemigration

4.2.2
Dos

Webi Report Development

OncetheUniversedevelopmentisfrozenandsignoffistakenthenstartthereport development. Standardtemplateofreportsneedtobefinalizedinconcurrencewiththebusinessuser whichincludeslogo,reporttitle,refreshdate,prompts,filters,formatofthepagei.e. alignmentsetcwhichshouldbecapturedwhiledocumentingtheRDD. Theabovestandardtemplateneedstobeprovidedtothedevelopmentteampriorto report/dashboarddevelopment. ReportdevelopmentdependsonRDDandstandardtemplatesofreport/dashboard requirements. ReportdevelopmentshouldbedoneinconcurrencewithRDDonly,anydeviationneeds toberaisedandtakenintochangerequest.

Chaitanya Bhure

23

 UnitTestingneedstobedoneoncethereportdevelopmentiscompletewhichnothing isbutdatavalidationandreportformattestingaspertheRDD. Qualityneedtobemaintainedasperstandardslikeproperfontssize,colors,headersof thetable,properalignment,subtotalfigures,totalfiguresetc.Thequalitycheckshould bedoneproperlypriortoreleasingthereportsforUAT. Oncetheunittestingandqualitychecksareperformedbythedevelopmentteamthe reports/dashboardsarereleasedforUAT. UATscheduleshouldbecommunicatedtothecustomer/businessuserwellinadvance andacceptanceneedtobetaken.Onceacceptedthebusinessusersshouldadhereto theUATtimingsotherwiseitwillimpacttheprojectdelivery. WhiledoingtheUATifareportortabnotfoundtobeinconcurrencewiththeRDDby theuserthensufficienttimetobetakentoincorporatethesameandagainthereport shouldbereleasedforUAT.Ifuserdoesnotrespondwithinstipulatedagreedtimethen thosereportswouldbeconsideredasacceptedandwouldbereleasedforproduction. OncetheUATissuccessfullycompletedforaparticulardepartment,immediatelythe trainingsessionneedstobeconductedfortheuserfromthatdepartmentandsignoff needstobetakenonreportsignofftemplate. ProductionisationofUATcompletedreportandusersignoffofproductionisedreports. Oncereportsareproductionisedonparticulardatethesupportstartsonthatdateitself. Thesupportisgivenonlyfortheexistingreports. Ifsomereportsaretakinglongertimefortherefreshthenitshouldbeproperly communicatedtothecustomerandadecisionneedstobetakenaboutthosereports withmutualunderstanding. Whiledevelopmentifdevelopmentteamcomesacrosscertainproductlimitationthenit shouldbeimmediatelycommunicatedwiththetechnicaluserofthecustomerand decisionneedtobetakenwithmutualconsideration.

Donts
TakingchangeswhiledoingtheUATnotmentionedornotcapturedintheRDD.This shouldbeavoidedandshouldbetakenaschangerequestandpropercommunication onemailaboutthesameshouldmaintain. Doingchangestoexistingreportwhileonsupport.Thisshouldbeavoidedandescalated tothecustomerandpropereffortsandcommercialneedtobecommunicated. Doingnewreportdevelopmentwhileonsupport.Thisalsoneedtobeavoidedandsuch activitiesshouldbecommunicatedandeffortstobeestimatedforcommercialandtime durationthusavoidingthedelay.Italsohelpsinmanagingtheoriginalprojectscope. Providingsupportbytheexistingdevelopmentteamonproject.Thisisnotbestpractice andsupportshouldbeprovidedbytheseparateteamandnotbytheexisting developmentteamasitmayhaveanimpactonongoingprojectdevelopmentandcan resultintoprojectdelay.

Chaitanya Bhure

24

WebiReportDevelopmentGuidelinesandBestPractices
Given below are the basic guidelines/practices that could be followed in any Report Design and Development.

General
Givemeaningfulnamesforthereporttabs Forcomplexreports,keepoverviewreporttabsexplainingthereport Usethereportpropertiestogivemoreinformationaboutthereportdataproviders Eachdataprovidershouldbegivenanamethatreflectstheusageofthedataits goingtofetch. SelectObjectsinsuchafashionthattheresultingSQLgivesahierarchicalorderof tableswhichhelpstoachieveSQLOptimization. Avoidbringinglotofdataintothereportwhichwillunnecessarilyslowdownthe reportperformance.

Report Variables

Followthenamingconventionof"var_"asprefixtoeachreportlevelvariable.This helpstoidentifyReportVariablesdifferentfromUniverseObjects.

4.2.3

Dashboards Development

DashboardsarethenewfaceofBI.Forafacetobeaffableandforadashboardtobe friendlytoyourbusinessthereareafewrequisitesthatneedtobeinplace. Businessintelligencedashboardisnotallthatdifferentfromthedashboardinyourcar.Tobe useful,itmustmakeyoudrivebetter,keepyoucomfortableandtellyouwhenyou're runningoutofgas,butwithoutdistractingyou.Let'slookatthetopfivedo'sanddon'tsof dashboardimplementationasgivenbelow. Do1:LettheDashboardBeBusinessdrivenandFocused AskBusinessUsers:whatcompetitivegoalsareyoutryingtoachievethroughthistool?What specificprocessesareyoutryingtomakemoreefficient?Whatcriticalinformationareyou tryingtomakemorereadilyavailableandwhy?Beruthlesslyspecific.Themoresurgically youzeroinonprecisetactics,thebetteryourchancetoachieveyourstrategyofgetting properinformation.

Chaitanya Bhure

25

Example:youwanttheinventoryofthetop10SKUstoalwaysremainoptimal,sothatyou're notoutofgoodswhilenevergettingoverstocked.Yousetupadashboardthatshowsthis informationinintuitiveeyefulingraphicformandofcourseinrealtime. Don't Don'tmakethedashboardintoalessunprofessionalversionofsolitaire.Toomuchfreedom andtoolittlefocus,andyouruserswillspendtimeonitforbringingnewthoughtprocess whichmightbe360degreechangefromwhatyouhavecapturedintherequirement gatheringwhichcanresultintodelayanddispute.Deliverwhathasbeencapturedin requirementgatheringanddontdeviatefromit.Ifusersaskforchangetreatitaschange requestandraisetheredflagthateffortsandcommercialsneedstobefrozenbeforemoving tothedevelopmentactivities. Do2:LettheKPIBeYourFriend What'saKPI?It'sakeyperformanceindicatorahandylittlecolorcodeddotorgaugethat "indicates"ifyour"key"itemsare"performing"wellorifthey'reheadedforthedogs.Seta threshold(e.g.minimummonthtodatesales)forthecriticalitems;whenyou'reonthegood sideofthethreshold,theKPIshowsyouagreendotallAOK.Whenyou'reonthewrong sideofthethreshold,theKPIturnsredtimetotakeaction. Example:soyouwanttohaveanoptimalinstocklevelofyourtop10SKUs.Have10KPIs thatalertyouwithoutevenhavingtoreadnumbers.Green:allisgoingwell.Red:eithertoo muchortoolittleinventory. Don't Don'tturnyourdashboardintothesinglescreenversionofthosemultiplesheetExceltables, whereyouhavetosortthroughmorefigures.EducateusersthedifferencebetweenWebi reportsanddashboardsandtheirobjectivessoastosettheexpectationrightinthe beginningitself. Do3:MakeYourDashboardActionable ItsgoodtogiveWhatIfindashboardwhereitmakesmoreuserinteractionandbrings satisfactiontobusinessusersforthetoolimplemented,sincetheycanderiveinformationon whichtheycanact. Don't Butforthesakeofmakingthedashboardinterestingdontputwhatifcriteriauntiland unlesssomebusinessvalueisdrivenoutofit.WhatIfarecomplexdevelopmentandusers tendtoaskformoreWhatIfeventheydontmakeanybusinessvaluewhichcanresultinto timeconsumingactivityanddelay. Do4:DashboardEstimation WhilewewereexecutingtheParleAgroprojectwheretherewere29dashboardswhichwe havetodeliverforthe10departments,whichwasherculeantask.Whatwehavemissed
Chaitanya Bhure

26

whiledoingtheprojectrequirementgatheringisourownanalysiswhichwouldhavereduced thenoofdeliverabledashboardsbyaskingmorespecificquestionsabouteachdashboards businessvalue. Dont DontevercountdashboardrequirementsintoWebirequirementatleastforeffortsand commercialestimationpurpose.Theyshouldbetreatedseparatelywhichwillavoidthe disputewhiledeliveringtherequirements,sincedashboardimplementationistotallya differentballgameandcomplexwherefactorssuchasLiveOfficeConnection,ExcelSheet, UniverseDevelopment,WhatIfcriteriaanduserthoughtprocessplayscriticalrole. Do5:Technical Datasetsshouldbeatahighlyaggregatedlevel. Usecolors,labelsandborderstoidentifycellsorrangesofcellsinthespreadsheet. Inspreadsheet,leaveroombelowandtotherightofyourdatasoitcangrowovertime withouthavingtoadd/removerowsorcolumns. Trytolimitdashboardsizetominimumtogetgoodperformance. Dont UseofSUMIF,COUNTIF,HLOOKUPandVLOOKUPfunctionsonlargerdatasets. Useofspreadsheetshavinglinkstootherspreadsheets. ModificationofreportsusedinDashboardthroughLiveOffice/QWAASconnection. InSummary Intheend,rememberthatthedashboardisjustatool.Theeasieritistouse,andthemore directlyitmakesyourcustomers'lifeeasier,themoreitwillbeadopted.Andthemoreitis adopted,themorepositivelyitwillimpactyourbusinessasavendor.

4.3 Unit and System Integration Testing 4.3.1

Chaitanya Bhure

ETL Testing
BasicValidationwithSource Validatingthecountofrecordsfromsourceandtargetdatabase(UnitTesting) maintainingtheDB_RECORD_STATUStableatthetargetdatabase. WorkingofappropriatebusinesslogicwhichdesignedintheETLflow Testingthejobsonthedailybasiswhicharesuccessfulornotbymaintainingthe DB_FETCH_BATCH_LOGtableatthetargetdatabase.

27

4.3.2

Report Testing
ValidatethereportformatandstructurewiththeRDD. ValidatethereportdataagainstthevalidatedDatawarehousedata. UnitTestingandSystemIntegrationTesting(SIT)oftheReportsandUniverseasperTest Plan.

5.0 DEPLOYPHASE
The Deploy phase is where all of the built and unit tested system is moved to the production environmentandthenfullytestedtoensurealloftherequirementsspecifiedinPreviousphases have been fulfilled. At the conclusion of the Deploy phase, the system will be transitioned into generaluseandturnedovertotheITdepartmentforongoingProductionsupport

Chaitanya Bhure

28

5.1 Perform UAT on Development environment

TheDataWarehouse/Mart,universe(s)andreport(s)willbetestedbytheuserfortheir accuracyintermsofdataandformatsonthedevelopmentenvironment.

Dos
ReportandDashboarddevelopmentshouldbedoneinaccordancewithRDDonly. Standardtemplatedesignforreportdevelopmentwhichincludeslogo,heading,prompt display,fonts,headingbackgroundcolorsandmargins(Header,Footer,LeftandRight margin)shouldbefinalizedbeforethereportdevelopmentworkstarts. DataisloadedinthetargetdatabaseaccordingtotheRDDandbusinesslogicdefined duringrequirementgatheringphase. Ifhistoricaldataisconsideredwhilebiddingtheprojectthendataqualityand consistencycomesunderclientspurview.Itshouldbenotifiedtotheclientthatthey havetoprovidethehistoricaldatapriortoUATanddatatestingisclientsresponsibility sincelotoftimeiswastedinthedoingthesaidactivityifitisnotproperlydefinedwhile biddingtheproject. AlwaysinformwellinadvancetheUATscheduletoclient. StandardizedExcelinputsfordatawarehouseshouldbegiventobusinessusersfordata populationwhichtheyarenotauthorizedtochange(excelformat).Thebusinessusers needtogivetheseexceldatawellinadvancetoimplementingvendorsoastoproceed withUAT

Donts
Takingchangeslikeadditionofnewelements,reports,tabsindevelopmentwhichisnot documentedinRDD.Thisshouldbeconsideredaschangerequestandshouldbe escalatedforeffortsestimationandcommercials. Forgettingtonotifytheclientthatoncethereportsaredevelopedandthebusinessuser insistsonchangingtheformattingofreportsthenitwillimpacttheprojectdelivery.It shouldbetakenaschangerequestandestimatedaccordingly. EntertaininglogicchangebroughtbyuserintheUATstagewhichisconsideredasa majorchangesinceitcanhavephenomenalimpactonUniverseforoneormaybe multipledepartmentsandthuscanhaveimpactonreportsfromoneormaybefrom multipledepartments.Itshouldbetakenaschangerequestandestimatedaccordingly. ForgettingtoraisethedelaybecauseofuserUAT
Chaitanya Bhure

29

ForgettingtonotifytheclientaboutHistoricalDatavalidation,cleansingandconsistency ofdatawhichneedstobeloadedintargetdatabasepriortoUATisnotvendors responsibility. ForgettingtoescalatethestandardexceldatainputformatchangebyuserwhileETL. Thisisagainamajorlossoftimesincethedeveloperneedstofindoutthereasonfor ETLfailwhileloadingtheexcelinput.Ifitisformultipleyears/monthstheneverything needstobetruncatedandloadedagainwithunchangedstandardexcelformatwith properdatabecauseofETLfail/improperdatainreportswhichishighlightedwhile doingUAT.

5.2 User Training

Dos
UsertrainingneedstobeconductedimmediatelyafterUATcompletionforaparticular departmentsincebiggapbetweenUATandusertrainingwillresultintolackof commitmentfrombusinessusers.Isuchscenariotrainingisconductedmultipletimes whichaffectsprojectdeliveryandprofitability. UsertrainingshouldbeconductedonlyonUATacceptedreportsonly. BItoolfunctionalityshouldbeshowningeneral(howtoaccesstheBItool,refreshing report/dashboard,differentwaystoanalyzethedatalikefilteringetc,howtopublish thereportsinvariousformatslikepdfetc,howBItoolwillhelpineliminatingthe manualeffortsetc)andnotatgreatdepthwhichmakesusersthinkofcomplexityof usingthetoolresultinginlackofinterest.

Donts
Forgettingtoinformbusinessuserswellinadvanceoftrainingschedule. Forgettingtoescalatetheissuesrelatingtodelayinusertrainingbecauseofnon availabilityofbusinessuseronthescheduletime.

5.3 Prepare the BODS XI 3.1 Production Environment

InstallationandconfigurationofBODSXI3.1onsupportedplatform InstallandconfigureBODSXI3.1serveronsupportedplatform. DeploynecessaryBODSXI3.1servercomponentsonsupportedWindowsplatform. InstalltheDI(DataIntegrator)functionsonSAPR3onproductionserver SAPR3authorizingthefunctionsforDItooperate(ToextractthetablesfromSAPR3)
Chaitanya Bhure

30

SchedulingtheDataIntegratorjobsinDataServicesManagementConsoleon productionenvironment.

5.4 Prepare the BO XI 3.1 Production Environment

InstallationandconfigurationofBOXI3.1onsupportedplatform InstallandconfigureBOXI3.1serveronsupportedplatform. DeploynecessaryBOXI3.1servercomponentsonsupportedWindowsplatform. ConfigureCMSandAuditdatabaseandcreatingRepositorydatabasesonsupported databaseserver. Tomcatserverinstallationonthesupportedenvironment.

5.5 Migration of Development to Production 5.5.1 ETL Migration

PromotetheDataIntegratorworkflowstotheProductionenvironmentbytwowaysdescribed below. Method1:Logontothedataservicesdesignerinthedevelopmentenvironmentand exporttherelatedprojectdirectlyfromthedevelopmenttotheproductionserverwith thecredentialslikerepositoryname,username/passwordofproductionenvironment.If thisprocessisfollowedformigrationthentheremightbesomeissueslikenetwork issue,powerfailure/fluctuationsetcwhichcancorruptanyenvironment. Method2:Logontothedataservicesdesignerinthedevelopmentenvironmentand takeabackupoftherelatedprojectonasharedfolder.Logontothedataservices designerintheproductionenvironmentandimportthatfilefromthesharedfolder.This processofmigrationcanavoidtheissuedescribedinMethod1ofmigrationprocess. Oncetheprojectisimportedsuccessfullyontheproductionenvironmentwehaveto runsomesamplejobsfortestingpurpose.

5.5.2

Report Migration

MigrationoftheUATTestedreportsanduniversestoProductionenvironmentcanbedonein twowaysasdescribedbelow.

Chaitanya Bhure

31

Byusingtheimportwizard Bysavingtheentireuniverseandreportsinthebiarfileandmigratingbyusingthe importwizard.

5.6 Review and Validation

Allthedevelopedworkflows,universe(s)andreportswillbetestedbytheuserfortheiraccuracy intermsofdataandformatsontheproductionenvironmentafterwhichthesystemgoeslive fortheusers

6.0 EVOLVEPHASE

Chaitanya Bhure

32

IntheEvolvephase,theprojectisformallycloseddown.AProjectclosureisconductedto ensurethatthelessonslearnedfromtheprojectarecapturedforfuturereference,andto identifytheopportunitiesforgeneratingfurthervaluefromanotheriterationofdevelopment.

6.1 Knowledge Sharing

Allthedocumentscreatedduringtheprojectwillbehandedovertocustomerandtheproject knowledgewillbesharedduringatwodaysknowledgesharingsessions.

6.2 Post Production Support

HandholdingtotheBusinessUsersandITDepartmentformaximumof10mandaysorasper theagreementwiththecustomer.

Dos
Oncereportsanddashboardsareproductionisedonparticulardatethesupportstarts onthatdateitself.Thesupportisgivenonlyfortheexistingreportsanddashboards.

Donts
DoingchangestoexistingDataModel(DW),Universes,WebiReportsandDashboards whileonsupport.Thisshouldbeavoidedandescalatedtothecustomerandproper effortsandcommercialneedtobecommunicated. Doingnewdevelopment(Universe/WebiReports/Dashboard)whileonsupport.This alsoneedtobeavoidedandsuchactivitiesshouldbecommunicatedandeffortstobe estimatedforcommercialandtimedurationthusavoidingthedelay. Providingsupportbytheexistingdevelopmentteamonproject.Thisisnotbestpractice andsupportshouldbeprovidedbytheseparateteamandnotbytheexisting developmentteamasitmayhaveanimpactonongoingprojectdevelopmentandcan resultintoprojectdelay. Databaselevelscripting,like,creation/modificationofviews,tables,procedures,etc. Thisagainshouldbeavoidedwhileonsupportandtreatedasnewdevelopment.

6.3 Exclusions
ResolutionofProductDefects. WorkingonanyBusinessObjectsEnterpriserelated activitiesthatarenotinthescopeof thecurrentdeployment. Any data cleansing is out of scope. Business Objects will assume that all the data that is providedwouldbecleanandreliable.

7.0 PROJECTORGANIZATION
Chaitanya Bhure

33

7.1

Vendors Roles and Responsibilities

ProjectManager:
Deliveringtheproject(s)withintimeandresourcebudgets. Requisitionofhuman,computerandconsumableresourcesandensureoptimumusage. Conductingperiodicalmeetingswithteammemberstoensureeffectivecommunication& feedback(upanddown). ProducingperiodicalstatusreportstothereportingauthorityandtotheCustomer. Ensure that the status report is regularly reviewed by the reporting authority and by the Customer,ifcontractuallyrequired. ImplementationofQualitySystemintheproject(s). Organize project walkthroughs and coordinate with QA for project audits or audits for a processtoensurethatthequalityobjectivesarebeingachieved. Ensure that project team members are always kept informed on matters of interest concerningtheproject/processandtheirwelfaretomaintaintheirmoraleatahighlevel. Proper usage of project management tool for effective project delivery on time, to manage change control mechanism and to ensure the optimum resource utilization so as toensureprojectprofitability.

BOConsultant:
Conducting smooth functioning of various integrations needed by Business Objects from SAPSystems. CoordinatingwithSAPConsultantsonCustomersitewhereadditionalinformationneeded tounderstandthecustomizationifany. WorkingincoordinationwiththeDevelopers. Ensure that all necessary documentation for the project(s) are prepared, maintained and approved,asrequired. Deliveringtheproject(s)inaccordancewiththeagreedcontract/workorder.

Chaitanya Bhure

34

Obtaining Customer acceptance on project completion, technical queries, changes and concessions,ifany.

Sr.Developer:
Deliveringtheproject(s)inaccordancewiththeagreedcontract/workorder. Monitoringandcontrollingtheprogressoftheproject(s). Obtaining Customer acceptance on project completion, technical queries, changes and concessions,ifany. Collaborating with the Customer executive(s) to ensure that Customer commitments are being carried out to clarify technical requirements and to resolve technical problems in a project. EscalatingCustomercomplaints,ifanyandcontractualissuesorproblemstothereporting authority and cooperating with the reporting authority to monitor their status & assist in theirresolution. Ensure that all necessary documentation for the project(s) are prepared, maintained and approved,asrequired. Reviewing design specifications to ensure correct use of common modules, correct interfacingbetweensubsystems,systemintegrityandoperatingefficiency. EvaluatingandsizingChangeRequests,ifany. SendingMinutesoftheMeetingstoalltheconcernedauthorities. WorkingincoordinationwiththeDevelopers.

Developer:

Chaitanya Bhure

Toperformallthetasksassigned. Maintainappropriatedocumentationandrecords. DemonstrateandimplementtheBusinessObjectsskills. Maintainweeklystatusandobtainnecessaryfeedbacks. Communicatethepotentialdelaysalongwithreasons.

35

Chaitanya Bhure

36

 7.2 Customers Roles and Responsibilities

This section details the Roles and Responsibilities, which Vendor has assumed, will be performed by Customer any deviation, which has a potential impact on Vendor responsibilities, will be subject to Change Control Process. Customer shall allocate/assign the requiredresourceswiththenecessaryskillsandauthoritytoexecutetheresponsibilitiesgiven below.

ProjectManager/Projectcoordinator
Customer shall designate a person, called Project Manager / Project coordinator to whom all Vendor communications may be addressed and who will have the authority to act for Customerinallaspectsoftheproject.Thespecificrolesandresponsibilitiesofthispersonare: SettingupandmanagingtheprojectteammembersfromVendor UpdateCustomermanagementontheprojectstatus. Foranychangeinscope, thecostimplicationsofthesamehave tobe considered.Forany changes there is a standard change request procedure for which structured processes needtobefollowed. Accept the deliverables or obtain the necessary acceptance signoff from Customer management,whereversorequired. Initiate and approve Change Requests or obtain necessary signoff and approval for the ChangeRequestsfromCustomerManagement. Ensure the availability of Customer management and users whom Vendor may need to discusswithforthepurposeoftheproject. FurnishallthenecessaryinformationrequiredbyVendorinconnectionwiththeProject.

Chaitanya Bhure

37

7.2.1

Customer Responsibility:
Toprovidetherequiredinformationanddocumentationassociatedwiththedevelopment effortfromendCustomer.

ToprovidetherequiredSoftwareandHardwarefortheproject. Topursuetheprojectandtocoordinatediscussions/demos/reviews/approvals. Toprovidetheacceptancecriteriafortheproject. To provide the required technical assistance on relevant end Customer applications that willbeusedbyVendorontheproject.

Toarrangefortherequiredresourcesaspercontract To ensure availability of required persons Customer for discussions, meetings, clarifications,reviewsandtestingatappropriatetimesaspertheprojectplan/schedule.

Toprovidequickturnaroundforapprovals,signoffsandacceptances. To provide quick turnaround for reviews, clarifications and answers to queries at various stagesoftheproject.

Toprovidethedevelopmentstandardsthatneedstobefollowed,ifdesiredbyCustomer To provide the necessary documentation support (For Example, Issue List) in assisting Vendorprojectpersonnelforexecutionoftasks.

To make undisputed payments to Vendor in accordance with the payment schedule on Vendorfulfillingitsobligations.

To conduct acceptance of all project deliverables within the time frame specified in the Projectschedule.

To ensure that the deliverables from Customer including Software, tools, test data and otherfacilitieswillbedeliveredtoVendorintime.

Toissuetheprojectacceptancecertificateuponsuccessfulcompletionoftheproject.

Chaitanya Bhure

38

8.0 DELIVERABLESANDACCEPTANCECRITERIA
8.1 Deliverables
AstheFixedBidEngagementthefollowingareDeliverablesgivenbelow SRSDocumentation DataWarehouse MappingDesigndocument ReportDefinitionDocument UniverseDefinitionDocument ETLDocument AggregateschemaandUniversestocatertotherequirementsofReports&Dashboards WebiReports Dashboards

8.2

Acceptance Procedure and Criteria

Dos
Upon completion of any deliverable, the vendor shall provide the UAT sheet which can be different for different requirements (Webi Reports or Dashboard) mentioning the various parameters like report elements, data refresh, report formats etc which should conforms to the description specified for such deliverable captured while doing Requirement Gathering and Analysis . Customer will be responsible for any additional review and testing of such deliverable in accordance with any mutually agreed Test Script&Resultforms. If the deliverable does not conform to the description for such deliverable, Customer shall have five business days after the submission of the deliverable (acceptance period) to give Vendor written notice which shall specify the deficiencies in detail. Vendorshallpromptlyaddressanysuchdeficiencies. After addressing the deficiencies, Vendor shall resubmit the deliverable for Customers review and testing as described above. Upon accepting any deliverable submitted by Vendor,Customershallprovidevendorwithwrittenacceptanceofsuchdeliverable.
Chaitanya Bhure

39

If Customer fails to provide written notice of any deficiencies within the acceptance period, as provided above, such deliverable shall be deemed accepted at the end of the acceptanceperiod.

Donts
Thedeficienciesconfusedwithchangerequestlikeadditionofnewelements,changein formatsofreportsagreedinrequirementgathering,changeoflogic(ETL),newreport development/newtabdevelopmenttosubstitutethedroppedreportsduetodata unavailabilityetc.Allthisshouldbetakenaschangerequestandproperdevelopmental andcommercialeffortstobeestimatedandnotifiedtothecustomerwellinadvance.

8.3

Sign off the User Acceptance Test (UAT)

Dos
Proper UAT document templates need to be created for various requirements (Webi and Dashboards). The template will have various parameters of user acceptance like for Webi Report the parameters would be Report Format, Data Refresh, Filters, Graphical Representation, Alerter (Working / Non Working), etc. All these parameters should be mentioned in the template and copies should be made with report name and code. Once the business user is satisfied with the UAT, his signoff is essential on the given template.Oncethesignoffisreceivedthereports/dashboardcanbeproductionisedfor daytodayusage.

Donts
ForgettingtotakethesignoffimmediatelyaftertheUATcompletion. Forgettingtoraisetheissueofuserdelayingivingsignoffevenaftersuccessful completionofUATwithinstipulatedtime,vendorneedstoraisetheissueimmediately asitmightdelaytheprojectdeliveryandaffecttheprojectprofitability. TakingchangeswhicharenotmentionedinRDDornotcapturedduringrequirement gathering.Ifsuchsituationarisesraiseflagofchangerequesttocustomerandtakehis concurrenceonproceedingfurtherwithproperdevelopmentandcommercialeffort estimationandcustomeracceptance. ForgettingtoinformthecustomerthatoncetheReportsorDashboardshasbeen productionisedafterUATsignoffitisdeemedtobeacceptedandinvoicescanberaised forparticularmilestone.

Chaitanya Bhure

40

8.4

Requirement Changes
IntheeventofchangestotheinitialuserrequirementsrequestedbyCustomerthesameshall be incorporated into the project plan and estimate of effort and delivery schedule will be revisedbasedontheextentofchangesrequestedfor. Customer shall approve the changes in plans and revised estimates in time for implementation. The revised schedule and cost shall be incorporated to the contract as amendments. Vendorwillreevaluateanysubstantivechangesfromthebaselinerequirementsandtechnical requirementsandwillfollowtheChangeControlProcess,whichtypicallyinvolves. Activity Requestforchange Studytheimpactofthe change Effortsestimatedueto impact ScheduleChange ApprovalofCostdueto effortrevision Signoffoneffortstoimpact Incorporatingthechanges Acceptance ChangeRequestClosure ImplementationVendor ChangeRequestform ImpactAnalysisform EstimationTemplate ImpactAnalysisform DevelopmentLifeCycle ChangeRequestForm Responsibility Vendor/Customer Vendor Vendor VendorwithCustomer consent Customer Customer Vendor Customer Vendor

8.4.1

Change Control Process

A change is initiated by a Request for Change (RFC). This is done by filling out a copy of the change request form and submitting the same to a Review Committee comprising of Customer Project Manager and Vendor Project Manager and/or their designates. Parties in writing will agree the membership of the Review Committee on commencement of the project.RFCcanbeinitiatedbyCustomerorVendor. The Review Committee will evaluate the RFC for technical validity and its impact on the project.Itwillalsodecidewhichpartyisresponsibleforimplementingthechange.Ifapproved by the Review Committee, the RFC will be forwarded to the party responsible. The party responsible will also be known as owner for the RFC. For urgent RFCs, a time period will be stipulatedbywhichthepartyshouldrespond.

Chaitanya Bhure

41

8.4.2

Response to Request for Change

Vendor will, within stipulated time of receiving an RFC approved by the Review Committee, provide the Customer with written acknowledgment of the receipt and estimate of time and effortrequiredtoanalyzetheRFCandpreparetheRevisedProposal. Depending on extent and complexity of the requested change, Vendor may charge for the effort required to analyze the RFC and prepare developmental efforts and commercial for the same. In such instances, Vendor will notify the Customer in writing of the estimated cost. The CustomermayrecalltheRFCafterreceivingVendorsacknowledgmentandestimate.

8.4.3

Customer Approval
ApprovalforAssessmentofChangeImpactand ApprovalforImplementationofChange.

Customerapprovalisrequiredattwostages:

When a change request with effort estimate, commercial and schedule is submitted to the customer, it needs to be approved by the Customer's authorized representative in writing. OnceapprovedbytheCustomer,theimplementationworkcanbeundertakenbythevendor.

8.4.4

Implementation

After Customer approval, Vendor will implement change request in accordance with the agreedchangedrequirements.Affectedportionswillbechangedandtested.

Chaitanya Bhure

42

9.0 PROJECTCOMMUNICATION&CONTROLMECHANISMS
The status report will be sent to Customer and the same will be discussed during the weekly reviews conducted through project meetings. However, any urgent issues will be immediately escalated and brought to the notice of the concerned person and an action plan initiated to resolvethem. All relevant team members from Customer and Vendor team will participate in the periodic reviews and contribute to resolve issues of concern. The forum will be used to surface issues thathavedependenciesonvariousactivitiesbeingcarriedout. Themodesofcommunicationwillprimarilybethroughemail.Othermodesofcommunication likeInstantMessaging(chat),telephoneconferenceandvideoconferencingcanalsobeused.

Chaitanya Bhure

43

 For Approvals and Responses on queries, these approvals should be given within the time limitsstipulatedwiththequery.ThedefaultresponsetimebyCustomeronqueriesbyVendor isconsideredasonebusinessdayandfeedbackondeliverablesastwobusinessdays. Once Customer has signed off documents, deliverables pertaining to the project, Customer is bound toaccept thedocuments.Anychangestothesignedoffdocuments,deliverablescould resultinchangerequestandtherebyinthedelivery scheduleandwouldaffectthecostofthe project.

9.1

How does one do Basic Level BI Project Management?

It is very essential to have a project management tool in place for managing, monitoring and reporting the BI/DW project progress as written in executive summary of this document.
Chaitanya Bhure

44

Manual monitoring instead of proper project management tool is time consuming with no proper analysis of tasks and milestones achievement which needs to be avoided. Manual monitoring can result into dispute and delay with both the vendor and client companies blaming each other for delay. Proper change control mechanism also could not be ensured because the process was all manual and a lot of time is wasted in estimation of efforts and convincingclientaboutthechange. Here are the methods by which you can do the manual monitoring in case you dont have proper project management tool. But this need to be avoided and given below are only guidelinesformanualmonitoring. DailyandWeeklyProjectstatusreports:Theseprovidethedetailswhichcanbe consolidatedforyourweekly,fortnightly,monthlyandmilestonemeetings.Atypical projectstatusreportwilltouchupontimelines,costandscope.Astandardtemplate needstobedevisedfortheaboveactivity. ProcessAdherencechecklists:Thesearethechecklistsusedtoassessprocess adherence.Astandardprocessneedstobedocumentedforeachstepofdevelopment likedesign,ETLdevelopment,ReportandDashboarddevelopment. CostAssessmentReports:Thesearetheexpensesheetsbasedonthevendorpayments andinternaleffortchargeout.Astandardtemplateneedstobedevisedforthesame. Steeringcommitteeminutes:Theyprovideaviewonthemanagementjudgmentonthe projectmanagementwhichincludesprojectmanager/teamleadfromvendor organizationandprojectowner/projectmanagerfromclientorganization. ScopeAdherence:Scopeadherenceisbothways.Firstlybeingabletodeliverwhatwas scopedoutbeforeandsecondlynottohaveascopecreepatthelaterstage.Scopefora BIprojectwillnotbeasingularstatement.Itshouldbenotifiedtotheclientthatonce scopeisfrozenanyactivityoutsidethescopewillbechangerequestandneedsto adheretothechangerequestcontrolmechanismorprocessforwhichitwillhave effortsandcommercialimplications.

Data Warehouse initiative is more challenging as compared to a transactional system. You betterreadittounderstandwhatyouareinfor. In spite of their proven ROIs for well implemented projects, the proportion of Data Warehouseprojectfailuresisfairlyhigh.Failurescantakevariousformsintermsof FunctionalTheprojectisnotabletodeliverthefunctionalityandanalysiscapabilities. TechnicalThetechnologyplatformandservicesdontwork. PublishingTheavailabilityofdataisnotasperexpectations. UsageEveniftheprojectiswelldelivered,thecapabilitiesandinformationisnotused.

Chaitanya Bhure

45

AchievementofbusinessgoalsEveniftheinformationisused,itisnotabletodrive theexpectedbusinessgoals.

Thedriverbehind thesefailuresisthathype&glamourofDataWarehousehasovertaken the diligence(especially,whenDataWarehouseandDataManagementinitiativesandknowledge base still to become a mass awareness and expertise). The diligence required is because Data Warehouseprojectsarequitedifferentfrombusinesssystemsprojects.Whiletypicalbusiness systems projects also may suffer from similar challenges, the intensity of them is much higher inDataWarehouseprojects.HereareDataWarehousechallenges,whichareunique

Chaitanya Bhure

46

10.0 RISKMANAGEMENT
Vendor will work with Customer to identify and assess all potential risks including cost of ownership and human resource constraints. Vendor undertake to provide a management approach that will ensure the best possible communication for the containment and effective handlingofthepotentialrisksassociatedwiththeimplementation. AreasofRisk Probability Implications Introductionofsuch changeswillimpact theprojectschedule. MitigationPlan Adheretoformal ChangeControl Procedures Detailedplanningand commitmentto project.AssignProject Manageratbothends. AvailabilityofCustomer resourcesduringthevarious phasesoftheproject. Vendorwill communicatethe businessusersin advanceabout meetingsrequirement forbusinesslogic discussion,System logicdiscussion,User TrainingandUAT SteeringCommittee proposedtoensure implementationof effectiveproject controlmechanisms Replacement consultantswillbe providedbyVendor withappropriateskills. Ifpossiblecontinue
Chaitanya Bhure

Changeinapplicationspecifics /design&guidelinesduring High development

High

Delays

Timelyescalationofissuesof concernandevolving appropriateactionplans

Low

Anyissuesofconcern thatareraisedatthe appropriatetime couldbesolvedso thatthereisno cascadingeffect

Nonavailabilityofassigned consultantsdueto unavoidablecircumstances

High

Delays

47

AreasofRisk

Probability

Implications

MitigationPlan withthesame resourcestillproject closureatleastTeam Leadershouldbe availabletillproject closure. DataCleansingwillbe donebyCustomer Customerwillprovide consistentdata. HistoricalDataUpload inDataWarehouse needstobediscussed withcustomerpriorto goingfor implementation,since mostofthetimethe dataisnotcleanand consistentwhichwhen loadedintotheDW giveswrong information.Insuch scenariosnormallythe customerblames vendorfordata mismatchwhich resultsintodelayand dispute.

DataQualityandConsistency

High

IncorrectResultsand delays

Chaitanya Bhure

48

Chaitanya Bhure

49