You are on page 1of 6

Business Blue Print Document

Business Blue Print Document (To-Be)

Process ID: BBP_FI_003_Fiscal Year Variant

Process Name: FISCAL YEAR VARIANT

Document Change History:


Version Date of Change Author Summary of Change
Draft 22.05.2013 Dhruma D. Vora Initial
Under 05.09.2013 Dhruma D. Vora Incorporated review comments with
Review User Champions
Final 05.09.2013 Dhruma D. Vora Final Version

Checklist
Business Event Description
 Are the Business Considerations and “To-Be” event descriptions complete?
 Are the descriptions clearly written? (Free of jargon, logically organized etc.)

Business Process Flow


 Have standard symbols been used?
 Do the flows reference appropriate manual and system points?
 Are the flows at an appropriate level of detail?

Other
 Have all interface and reporting points been identified?
 Have all development items been identified and documented?
 Have differences between current and To-Be processes documented?
 Have all issues been logged in the issues log? Cross Referenced in this document?
Attached to this document? (functional, technical, conversion, development, change
management)
 Have all the gaps been documented?
 Have all high-level conversion considerations been documented?
 Has the application architecture been updated to reflect interfaces?
 Have all referenced items been noted and attached where appropriate? (Spreadsheets,
Functional information papers, etc.)

Business Event Summary


Process: FI _ FISCAL YEAR VARIANT
Sub- FI _ FISCAL YEAR VARIANT
Process:
Event Fiscal Year variants determines the number of posting period
Description: and special period.

Page 1 of 6
Business Blue Print Document

To-Be processes

TO-BE: Proposed Business Process Description


Document future To-Be process based on system requirements. Note which tasks are system vs.
manual transaction. Also cross-reference the number of each task to the number of step in the
process flow diagram.
Activity / Task System
No. Activity / Task Description
Name Transaction
01 Fiscal year and The Fiscal year defined as a variant which is OB29
Fiscal year variant assigned to the company code. Standard fiscal
year variants are already defined in the system and
can be used as templates. The fiscal year variant
contains the definition of posting periods and
special periods.

Page 2 of 6
Business Blue Print Document

02 Fiscal Year CIPLA will use following Fiscal year variant OB29
Variant
Fiscal year variant

V3 ( April to March, with 4 special periods - for


leading Ledger)

V3 ( April to March, with 4 special periods - for Non


Leading Ledger)

One non leading ledger will be created for IFRS


purpose. Entries for IFRS ledger will be on the
same basis of leading ledger however going
forward based on the changes in regulation
necessary setup will be created for the purpose of
compliance to IFRS and adjustment entries can be
posted to non-leading ledgers.

Please refer below for details relating to leading &


non leading ledgers

Month Days Posting


Periods
April 30 01
May 31 02
June 30 03
July 31 04
August 31 05
September 30 06
October 31 07
November 30 08
December 31 09
January 31 10
February 28 11
March 31 12

Page 3 of 6
Business Blue Print Document

Process Flow Diagram:

(To-Be) Not Applicable

(As-Is) Not Applicable

Page 4 of 6
Business Blue Print Document

TO-BE: Development Items


Record development objects. Specify their type (I = Interface, R = Report, E = Enhancement, C
= Conversion, F = Form, W = Workflow) and priority (1 = Mandatory, 2 = Workaround required if
not implemented, 3 = Optional) required. Also cross-reference the number of each task to the
number of step in the process flow diagram.
No. Type Description Priority Ref. To-be Step(s)
01
02

TO-BE: Identified Business Work Practice Change


Document the identified business work practice changes to the As-Is process ( Nature of
Changes would be S- System; R – Roles, P- Policies)

Sr. Area Nature of Current Practice in SAP


No Change Practice

TO-BE: Pain Points and Associated Business Impacts


Document the identified Pain Points in the As-Is process and their resolution

Sr. Pain Points Business Resolution Comments


No Impact

As-Is Document Referenced


Document the list of As-Is documents referred in this To-Be process

Sr. As-Is Document No As-Is process Name


No

TO-BE: Identified Business Impacts


Document identified impacts to the business. Specify impact category (OG = Organisation, OP
= Operation, CU = Customer, OT = others) the level of criticality based on depth of business
impact or size of gap (H = High priority issue or benefit to address, M = Medium sized gap/
impact, L = Lower priority to address).
No. Description Impact Category Impact Level Mitigation

Page 5 of 6
Business Blue Print Document

TO-BE: Identified Regulatory Impacts


Document identified impacts regulatory Impacts to the business. Specify as H – High; M –
Medium; L – Low. If the process has no regulatory impact mark as NA.
N Description/Potential Failure Probability of Severity Overall Mitigation
o Occurrence of Impact Impact
None

Additional Documents Referenced


Enter the location for all other documents which are referenced here. Enter the full path of the
file. Enter a brief one line description about what the document contains. (E.g. Business
Blueprint, Process Flows, Development Inventory, Issue Logs, etc.)

This BBP document is signed off based on following assurance:


1. Accenture will provide appropriate solution to meet the requirement as described in the ‘TO BE’
and the relevant ‘FIT GAP’ document.
2. Any change should be mutually agreed upon by both Cipla & Accenture and will be recorded as
an addendum to the BBP document.

Sign Off

Sign-off
Please sign and Date. Name Signature Date
Process Owner V.S.Mani

Core Team Member Ramnath


Vaibhav Vaidhya
Sandeep Narang
Datta Sharma
Pravin Mungekar

Functional Consultant Dhruma D. Vora

Quality Assurance Pravin Bhatkulkar

Page 6 of 6

You might also like