SAP BA implementation Experiences - Time to revise the implementation approach

• SAP BA implementation require a lot of technical expertise (BW/BI -advance level expertise on BW workbench, TOOL BI, ETL,LSMW, PI Interface communication (flat file, XML, BAPI or direct PSO or consuming real time front office operative data) so that reconciliation or any mismatches can be identified or ensured that implementation / design  with exception / error testing is fit for the purpose
• Integration architect role- critical as like any ERP implementation from technical aspects of the solution implementation

Collaborative approach that includes Architecture, Finance, IT and operational experts, agreed – this is case of any solution in the ERP landscape –

• Foremost & important role” in SAP BA implementation is the Finance Accountants (SMEs) who understand IFRS –IAS disclosure / reporting reqs -  not a high level but as low as individual transaction level, expert can review blueprints, input to testing, develop sample data cases/ strategy (which I believe is the heart (back bone of the SAP BA testing)  

• Data management itself is critical for successful implementation and for ROI, that’s why SAP BA has archiving concepts in BA – this facilitate correct – predictable analytics -   I don’t think need for  quality data can be ignored for pre-implementation  -  correct  raw data mining & controlling thought-out the testing life cycle for recognition, registration, valuation & classification  and again derecognition, imbrutement  from existing posting,

• We do understand a single distinction of the data (FT, BT)  from its life cycle can change the expected accounting behaviors / results  - You will agree – IFRS is changing e.g. recent changes in the IAS 36 for “Impairment of Assets” made industry  more vigilant with solutions such as  SAP BA

I also observed some time necessary resource / talent lack on the implementation (technical or functional) as SAP BA is bit new in industry compare to FICO - Some time SAP BA creates a very large number of “account combinations” and journal lines from the transaction on the given period end (KDV- EoD)- Number of values in each segment, composition of the extended accounting etc-  idea is to ensure accounts covered in the transaction do not relate to the same sub ledger - otherwise the transaction becomes an intra-ledger transfer – this is a good feature of solution like SAP BA, but as someone like SME not being available on the project, this good feature was modified  in one small implementation  then reverted after almost 4 months discussion …

In many organizations, BA had become not only the system for financials AFI and regulatory reporting, but also a system for operational management, planning tool and reporting to internal performance with SAP BPC etc . Hence, if any of the SAP BA project oriented organization lacked a strong talent for project accounting and management – It must be looked a resource rather SAP BA solution..

Compiling  daily data for  profit and loss or balance sheet reporting, determine appropriate accounting treatment (eg under IAS39) - Period end related analyses / procedure from accounting perspective -

projects must been ready for surprises and new lessons learnt. As my career in QA and testing, I believe SAP implementation scenarios is the easiest one provided right recourses are doing right job…

#Individual must be strong in both accounting for financial instruments (IFRS -GAPP) and the mechanics in Bank Analyzer/BW required to address the client’s reporting and disclosure requirements

Data sourcing and reporting teams to ensure a cohesive end-to-end solution. Be a Package Solution Consultant SAP BA project. One must not just solving IT problems but understands and works with finance …

SAP Test Techniques

SAP test techniques applicable at a basic level on sap package / component solution customization level –

Fully not applicable on a SAP upgrade

Other applicable test techniques applicable are :  Condition Testing &  Data Flow Testing

Condition testing is a test case design approach that exercises the logical conditions contained in a program module.  A simple condition is a Boolean variable or a relational expression, possibly with one NOT operator.  A relational expression takes the form

where  are arithmetic expressions and relational operator is one of the following <, =, , (nonequality) >, or . A compound condition is made up of two or more simple conditions, Boolean operators, and parentheses.  We assume that Boolean operators allowed in a compound condition include OR, AND and NOT. 

The condition testing method concentrates on testing each condition in a program.  The purpose of condition testing is to determine not only errors in the conditions of a program but also other errors in the program.  A number of condition testing approaches have been identified.  Branch testing is the most basic.  For a compound condition, C, the true and false branches of C and each simple condition in C must be executed at least once. 

Domain testing needs three and four tests to be produced for a relational expression.  For a relational expression of the form

 Three tests are required the make the value of  greater than, equal to and less than , respectively. 

 Data Flow Testing

The data flow testing method chooses test paths of a program based on the locations of definitions and uses of variables in the program.  Various data flow testing approaches have been examined.  For data flow testing each statement in program is allocated a unique statement number and that each function does not alter its parameters or global variables.  For a statement with S as its statement number,

DEF(S) = {X| statement S contains a definition of X}

USE(S) = {X| statement S contains a use of X}

If statement S is an if or loop statement, ifs DEF set is left empty and its USE set is founded on the condition of statement S.  The definition of a variable X at statement S is live at statement S’ if there exists a path from statement S to S’ which does not contain any condition of X. 

SAP Banking Servcies (BaS) and SAP Bank Analyzer

At High level for Banking Services, following is the Set up of new bank -

• Sap business partner for financial services (SAP BP –CRM)
• Product and order management (Based on products Loan –CML , AM, DM or IA)
• Foundation set up such basic bank keys, bpa, master agreement etc
• Pricing financial conditions based on product line - country specific
• Settlement - Settlement  rules  - Extended settlement  daily EoD, differ or other per Kyc etc
• Payment transactions - direct posting, accrual or realization based on SO etc
• Currency exchange - config
• Posting checks , Posting lock management - direct posting, accrual or realization based on SO etc
• Posting control office - work flow 
• Posting control rules  - work flow   etc
• Account management
• Master contract management
Effective cash pooling
Bundle pricing
Interest compensation
Charge compensation
Facilities
• Collateral management
• General ledger transfer
• End of day processing
• Post processing office
• Release tool

For Bank Analyzer - essential from technical front is good knowledge of ABAP/BAPI, BI (data feeder) – and knowledge of Index, ALV and work list etc –
Functionally – Accounting (thick ledger concepts)  IFRs reporting and Fair Valuation knowledge is important, just data feed, data flow doesn’t give full coverage for implementation  BA -  it is said, BA implementation might be right but does it do right things for business, must have Accounting principal understand not just limited to Dr & Cr but low level micros accountings of transactions as :
Ensuring, reviewing that feeder system data (that is banking transactions) are accounted for in the optimal way under IFRS to minimise income statement and equity volatility.
In-depth knowledge of banking products and their impact on banking volatility using appropriate / applicable accounting rules to be configure in the SAP BA system
Hedge, stress, merge cases from a micro accounting perspective
IFRs reporting, MI and analytics, reconciliation (n dimensional)  to assess various accounting relationships, balance processing  with  Finance teams as part of the strategic accounting reporting process, and understanding of Front Office teams system transactions as part of the day-to-day activities – map activities to SAP BA data conversion as source layer (ETL/BI, DLL,SDL to processes & finally mapping to RDL – full understanding of the processed data to accounting information - & valuation understanding)
Compiling  daily data for  profit and loss or balance sheet reporting, determine appropriate accounting treatment (eg under IAS39) - Period end related analyses / procedure from accounting perspective -
Retrospective and prospective testing of accounting relationships to ensure compliance applying identification, designation of accounting entries
On top of all, be successful in SAP banking (either be transactions or analytical – important is a good knowledge of banking products, processes (retail or investment) and for SAP BA - the accounting for financial instruments knowledge –
An aptitude and willingness to learn Functional / Business & IT processes
Good Luck all…

AFI- Accounting for Finance – how does SAP BA fit into context

AFI- Accounting for Finance – how does SAP BA fit into context - further detail to follow.

 

 

 

bonfire; warm, bright, a bustle of comforting assumtion of software developemnt ....Testing is exploration of darkness....

On top of all typical marketing language and beyond the typical SDLC, either it be a SAP implementation or standard IT delivery, one of the assumption is being applied that solutions is going to work as expected but to prove it does works or not - there is always need for an intelligent testing & when we are talking about finance product testing – I don’t think a traditional testing methodology works well…

Foundation finance testing practice, that are rock in the soil that protects efforts against harshness of unexpected) -  

Other than Why? What? & How to test, require destructive testing activities, a deeper level of understanding of the “banking products accounting principals” starting from a order / contract origination to its life cycle events and test conditions surrounding to normal to abnormal life cycle and above all understanding of the data transformation, enrichment rules that system coverts into an accounting  - be it thick  or thin ledger a/c event -  transactions composed of intricate and highly ramified GL transactions help to discover events or finance requirements during the realization phase ---

How the tests should be carried out also require strong planning of each activity –As well said..“Software application implementation is a cozy bonfire; warm, bright, a bustle of comforting concrete activity. But beyond the flames is an immense zone of darkness. Testing is the exploration of this darkness.” - Extracted Software Maintenance technology magazine.

 business architect or dedicated integration lead is critical for an integrated system but someone with a brave accountancy mind tester can uncovering underlying defects or gap in requirements that could be impacting overall system in real life – as in testing language, it is said, the objective of any tester should be to try his best to crack the application feature /code. This might be seen as a destructive activity but it worth to spend money   …

Even though there's no denying the fact that Construction/Coding is a very significant phase in the life cycle of any application but same time to Reduce Costly Errors in future, destruction can also be performed –

 Some time complexity is due to several factors, some of these being: the high level of coordination needed to ensure that all accounting consequence data inputs are available or identified, generated, and managed through test life cycle…. Time is saved when experts performing the activity – both technical as well as business, business can identify what need and in what way will it be used using application however deliberately intense or thorough testing to determine the stability of the system  -It involves testing beyond normal operational functionality, to confirm intended specifications are being met; to determine modes of failure (how exactly a system may fail), and to test stable operation of a part or system outside standard usage e.g.  Posting of the wrong amount, omitting a posting, posting in the wrong area or posting more then once for in the given period – simulating source systems behaviours or applying test to thick ledger areas that may impact asset, liabilities or equity with retain earning before preparation of net income - cash flow statements drive from the finance statement so  either direct or indirect methods, test closing entries on period-end and leave one side of the balance open so the impact of the imbalanced figure from source to suspense account in GL is tested or error discovered - Prepare reverse entries deliberately simulating the discrepancies of accountancy --

It has transcended to an age of modern-technological level. With that, the demand for a more efficient system of managing finances and finding a better means of exchanging data are at an all time high, I remember a roll out of a multi million software product to market, which was like a story of Toyota Car -recalling 7m cars worldwide because of minor fault –

Software (SAP ECC or BA) it handle all of the arduous accounting work but need robust config and exception management. Finance applications focus on looking for ways on how to develop profitable business hence portfolio management testing where stress tests in payment, finance for current and future settlement is critical can also be the aim of testing.

SAP BA has full feature of management, cost and finance accountancy therefore what is being developed/ customised require testing in one go  of the implementation.. The end-aim of the system is meet finance requirement which is meet the cash flow in and out assessment on given day or period  - Strategic vision can help to deliver but ground reality is often unpredicted.. Product accounting system (SGL) need knowledge from basic journal entry of the finance conditions to bank book value to GL derivation to aggregation based on the IFRS – Fair valuation or reconciliation - all  can be tested

I believe Business process flow is always same for all accounting/ finance reports; it has been same in the industry for ages but the way of collecting, analyzing, summarizing and evaluating has changed and facilitated with applications – either it be item of debit or credit – it has not changes but the identification, registration, calculation and classification of transactions / events in a cognizable manner has forced to change because of finance meltdown (IAS/ IFRS,GAAP, MTM standards etc…..

Learning Is a Treasure That Will Follow Its Owner everywhere...A good teacher is like a candle - it consumes itself to light the way for others.