Discuss business intelligence, integration, compliance and a host of other SAP-related topics – implementation, best practices and resources to negotiate the world of SAP better!

April 15, 2014

Flexible Data Governance - Oxymoron or Practical need?


The need for data governance which actually means establishing control on data source to obsolescence has become a need for many organizations. I would be surprised if any CIO is not mentioning establishing data governance or enhancing data governance as one his primary IT investment objectives in the short term or long term. Lot of organizations have a baggage of multitude of IT systems each of which serves a specific business need and designed to serve it by sourcing the needed data all by itself. All organizations always keep evaluating the conflicting need to rationalize IT systems or building more robustness in the interfacing part so that the hold on to the best of the breed IT systems even though collectively they create lot of weak links. So if an organization is able to rationalize IT systems, then data governance is taken care by the rationalization itself but in case of the need to maintain the best of breed IT systems, then data governance becomes paramount as it can really break the weak links and exponentially increase the pain of maintaining such heterogeneity.


So the context of data governance is to arraign the sources of proliferation of data elements and data values and bring in much needed control. Basically strengthen the weak links in the heterogeneous IT systems landscape which I had mentioned earlier. As anybody can guess this is easier said than done. Additionally data governance needs harmonization as pre-requisite which can also turn out to be tough to crack. So achieving one source of truth and one value across all the IT systems is a tall order, but then is it not the fundamental requirement to be achieved through Data Governance. It is here my topic bears significance of having flexibility in data governance. I would say "Flexible Data Governance" is indeed an oxymoron but it is a practical need too. Let me explain with an example.


In a recent data governance implementation project we came across the field "Division" having available values as 10, 20, 30 & 40 in one SAP system and in other SAP systems there were multiple values additional like 60, 15 and even alpha numeric of two character length. Keep in mind all the systems involved are SAP, so it should be a piece of cake to harmonize this and that is how it started. We standardized the values as 10, 20, 30 & 40 in the data governance system and mapped the additional values available across all systems to these 4 values. But then we found case of hard coding in interface programs, middleware program, enhancement programs and even values in this field being used in user exits to execute specific activities etc. which ruled out harmonization of one value of after another. So what to do? Continuing with harmonization means costly program changes, elaborate testing efforts, risk of introducing production issues etc. Here comes the concept of "Flexible data governance" where-in we introduced scalable data governance where-in within a master data object we allowed values to be harmonized and controlled on a certain fields while in other fields it is allowed to have different values in different systems. So the data object is part of data governance but not all fields in it are controlled by the data governance tool.


I am sure each of us would have seen such conflicting requirements, but in a data governance project where-in the fundamental need to conformity, flexibility is a bad word but then life thrives in the gray. Please share such examples in your project experience.

April 4, 2014

Development and support with Scrum; an integrated approach

The Scrum development methodology since a few years has been well integrated into the IT department of many organizations. It is considered to work well for numerous reasons

- Communication is vital to success in any project. Scrum promotes communication between project team members

- Scrum shows quick results. One or two iterations (sprints) are sufficient to show a working product to the client

- No time is wasted as all items are prioritised based on the business value

- The production team is a self-organised unit that works to reach the Sprint Goal on time. A mix of skill sets and skill levels are often ideal to promote a continuous work flow.

- Scrum promotes transparency: the client knows what is going to be delivered in the sprint, since he/she has prioritised the Product Backlog.

All success of the scrum team is focused on delivering a working product on time and meeting the quality standards defined. With the sharp timelines set in the sprintplanning, the support team often experiences a lack of knowledge handover by the development team. The support team is often left clueless of what code has been brought live at the end of the sprint cycle. Once the new code is in production it is difficult for the support team to perform issue analysis, as the team never received a proper knowledge handover.

In this article I would like to cover my experiences in Scrum development and the actions that were taken to mitigate the risks of poor handover of scrum products to the support team. A brief reminder of what Scrum methodology is; scrum is one of the Agile development methodologies that uses time boxed effort, known as Sprint cycles, to develop a working increment of a software. Sprint cycles (usually) last 3 weeks, in which requirement analysis, development, testing and documenting are all being performed. Which requirement are to be build in a Sprint are determined from a Product backlog (pool of user requirements) determined by the user community and moved into the Sprint backlog for planning. Each item on the Sprint backlog is called an Epic and can be narrowed down into separate pieces of coding called Stories. In order to determine the effort for bringing each Story live, Pokering takes place, determining how many Stories can be handled within a Sprint with the available resources. Every day team members gather in a Standup to discuss the work done yesterday, the planning for that day and possible impediments, in order to track the progress of each Story. After 3 weeks a review takes place of the work that was completed and not completed and a go/no go decision to Production is made. Finally in the Sprint retrospective all team members gather to discuss the past Sprint in a Retrospective, determining what went well and what the improvements are for the next Sprint.

The process is simple and logical; a scrum team has set its goal at the start of the sprint cycle, performs the tasks in de sprint, revises if needed and at the end of the cycle assesses the success of the sprint by its products. Unfortunately, nowhere in the process, handing over its knowledge to the maintenance team has been mentioned. It would look like the development team considers the delivery of the coding to production as the final stage of product, whereas it is actually the start of the functionality being used and support by the maintenance team begins. Considerable literature has been written on best practices for knowledge management in a Waterfall model. Knowledge transfer is often taken as a phase in the project delivery. Often at the end of the project execution project members would spend time discussing the newly implemented processes and functionalities to the maintenance team, or even involve them at an earlier stage (eg during requirement analysis or testing). Involvement and participation from the support team seems much easier to fit in a timeframe of a year or longer in case of waterfall, then in a sprint cycle that only lasts a few weeks.

Then how can we better prepare the maintenance team for the upcoming product releases, without interfering the development team in their tight delivery schedule? Introducing the Development-Support integrated Scrum model:

Development-Support integrated Scrum model.PNG

View image

The Development Support integrated Scum model adds a series of easy executable handover milestones in the existing Scrum model that tests the quality of product and delivered documentation as well as the readiness of the maintenance team to start supporting the functionality. The idea is to transition the product of a stage to the support team as soon as the development team finishes a certain stage in their sprint cycle.

The first stage for the development team in the sprint cycle is to determine the Sprint backlog; which epics and stories are committed to be delivered in the coming sprint. The list of epics are immediately communicated to the support team, so that they can prepare for what is coming. A Subject matter champion (SMC) in the support team will be assigned who will align with the developer for the remainder of the sprint execution. Requirement and solution documents that are available for the development team are also made available to the support team.

In the second stage handover the developer has finalized the solution of the epic. It can be on a minimum functional level or could be on a detailed technical level. In a short 15 to 30 min session, the solution is explained to the SMC, who at this point will have an understanding of why and how the solution will be build.

In a third stage handover the functionality is delivered by developer. It is ready for the SMC to perform some simple unit tests or integration tests on its own. This ensures that the SMC understands the functionality on a practical level and could even help the developer in finding bugs in the coding.

In a fourth stage handover the developer should have finished the necessary documentation of the functionality. What was not worked out in detail in the second stage handover should now be extensively described in functional and technical documentation or work instructions. It's the task of the SMC to check the quality and the completeness of the documentation.

In the fifth and final handover a stage is given to the SMC to show to the development and maintenance team what he/she has learned from all handovers in a Reverse Knowledge Transfer session. In short he/she will explain the rationale of the requirement and the solution. He/she should also be able to show the exact changes in the code in the system. To finalize the last handover a sign off takes place between development and maintenance team on the following objects

- Functional design documents

- Technical design documents

- Process model documents

- Business requirement documents

- Open issues list

- Performance testing documentation (if applicable)

The final handover is the official handover of the product to the maintenance team. The functionality is now ready to be supported in a live environment.

The Development- Support integrated Scrum model is way of working that is easy to implement for the developer, but intensive for the SMC; the developer at the end of every sprint stage (design, build, test, documentation) only needs to spend a short time to hand the product of that stage over the maintenance team. The SMC on the other hand has to spend a substantial amount of time through reading, analyzing and testing the coding. As the SMC will find this necessary to perform quality support of the functionality, this is not seen as an objection.

The Model is a good way to perform checks on every product of the development team. What is the quality of the coding, documentation and testing. And as the check is done immediately after the release of that product, corrections are easier to make. You need not wait until the end of the sprint to perform these checks. There would have been a greater resistance to perform corrections when the Agile team is already well underway in the next sprint.

The Integrated Scrum model is foremost an integration model. The maintenance team will feel more involved in the sprint cycle and be better prepared once the product is brought live. And that should be the ultimate goal of Scrum: to deliver a quality product that works in production. And if it doesn't work, then any issues should be resolved with little effort.


January 9, 2014

Operational integration in country organisations

The customer facing automotive supply chain has evolved over the years in a tiered fashion considering the product lines, the dealership structure and the legal regulations in countries. It has resulted in a multiplicity of organisational units which are quite adept and responsive to the needs to of the customer, but leave a lot of optimisation and efficiency potential to be realised. The potential is even more discerning given the way IT has evolved over the years in finding new avenues for business to be leaner and agile. The overarching aim of the business to harmonize, consolidate and automate business processes is deeply embedded in the desire for a new integration and optimization paradigm which is taking shape at the country / market level.

Continue reading " Operational integration in country organisations " »

January 7, 2014

Bitcoins - should we care?

News has recently been dominated by the development of the value of Bitcoins. The price of the digital currency has risen from 250 USD from beginning November to a record high 1065 USD on December 8th only to drop half of its value in 24 hours again. Chinese government has prohibited national banks to trade in the currency as it indicated the Bitcoin has a high risk of being used by criminals and for money laundering. This has led to Chinese leading social network Baidu, which used Bitcoins as a trading currency, to stop excepting them. China's high powers evidently felt that the cryptocoin was getting too hot to ignore. So is Bitcoin here to stay or is it just another digital hype?

So for those who are not aware of the currency, what are bitcoins and what's it's use? Bitcoins were invented by a developer under pseudo-name Satoshi Nakamoto in 2009. Bitcoins are not tangible but only exist as a piece of code in a peer-to-peer payment network that is powered by its users with no central authority or middlemen. How are Bitcoins created? New bitcoins are generated by a decentralized process called "mining". This process involves individuals who are rewarded by the network for their services. Bitcoin miners are processing transactions and securing the network using specialized hardware and are collecting new bitcoins in exchange for their services. You can compare the function of this network of miners similar to a central bank, authorized to print and distribute the currency. How are Bitcoins used? From a user perspective, Bitcoin is nothing more than a mobile app or computer program that provides a personal Bitcoin wallet and allows a user to send and receive bitcoins with them. Behind the scenes, the Bitcoin network is sharing a public ledger called the "block chain". This ledger contains every transaction ever processed, allowing a user's computer to verify the validity of each transaction. As Bitcoin is a cryptocurrency; for each transaction, the bitcoin receiver shares a public address where the amount can be send to. With a private key, the receiver can then digitally sign the receipt. How do we know it's secure? The Bitcoin specification starts with the concept of a distributed timestamp server. A timestamp server works by taking a hash function of some data and widely publishing the hash. For Bitcoin, each timestamp includes the previous timestamp hash as input for its own hash. This dependency of one hash on another is what forms a chain, with each additional timestamp providing evidence that each of the previous timestamp hashes existed. To form a distributed timestamp server as a peer-to-peer network, Bitcoin uses a proof-of-work system often referred to as Bitcoin mining. Anybody can become a Bitcoin miner by running software with specialized hardware. Mining software captures transactions broadcast through the peer-to-peer network and performs appropriate tasks to process and confirm these transactions. For new transactions to be confirmed, they need to be included in a block along with a mathematical proof of work.

Bitcoins are created at a decreasing and predictable rate. The number of new bitcoins created each year is automatically halved over time until bitcoin issuance halts completely with a total of 21 million bitcoins in existence. When taking todays Bitcoin value (15 dec 2013) of 872USD, this means that the ultimate value in circulation is approximately 18 billion USD. One would consider this is as just a small amount compared to currencies such as Euros and USD's in circulation. But 2 important things should be considered. First the currency is only worth, when it's being used. When money is deposited on a savings bank and not spend, it's useless. Bitcoin payments are easy to make and can be used for small payments against minimum fees. If a bitcoin is being rotated from owner every day, the trading value per year can ultimately develop to 6 trillion USD, more than the Indian yearly GDP. Obviously, the circulation rate will not be once in 24 hours, but the advantages to do so are known. We will come back to that later. Second, a digital currency is a good replacement for national currencies that are non-tradeable or problem plagued. It's best example is the Chinese Renminbi which is only allowed to be exported or used in international transactions on a limit base, ultimately making it less advantageous for consumers to hold on to, unless they travel to China often and have the opportunity to spend it. For this reason Bitcoin is seen as a perfect substitution for Chinese consumers making payments outside of China. One third of all Bitcoin transactions are performed by Chinese. Also when a currency is plagued by volatility, the Bitcoin can be used to circumvent inflation, capital controls, and international sanctions. Bitcoins are used by some Argentinians as an alternative to the official currency, which is stymied by inflation and strict capital controls. In addition, some Iranians use bitcoins to evade currency sanctions.

Another major advantage of Bitcoin payments are that there are either no fees or extremely small fees. Users may include fees with transactions to receive priority processing, which results in faster confirmation of transactions by the network. Additionally, merchant processors exist to assist merchants in processing transactions, converting bitcoins to a currency of choice and depositing funds directly into merchants' bank accounts daily. As these services are based on Bitcoin, they can be offered for much lower fees (a payment of 0.0005 BTC for a 1,000 BTC transfer) than with PayPal or credit card networks (which usually request a 1 or 2% fee over the transaction amount)
Moreover, Bitcoin payments can be considered as secure, controllable and transparent - Bitcoin users are in full control of their transactions; The recipient holds a private key which is kept secret. Only the private key can decode information encrypted with the public key; therefore the keys' owner can distribute the public key openly without fear that anyone will be able to use it to gain access to the encrypted information. All information concerning the Bitcoin money supply itself is readily available on the block chain for anybody to verify and use in real-time. No individual or organization can control or manipulate the Bitcoin protocol because it is cryptographically secure. This allows the core of Bitcoin to be trusted for being completely neutral, transparent and predictable.

Even with the Chinese government banning the speculation of the currency by its banks or act as a middleperson for bitcoin payments, it seems like the Bitcoin use is unstoppable. Just todays issue of Business insider published that a Swedish company has sold 28 million USD worth of bitcoinminers, which has the processing capacity to mine around 4000 bitcoins per day. Techies show that bitcoinmining is lucrative and will stay lucrative until the last Bitcoin has been issued. And with its transaction processing advantage, more and more retailers are allowing customers to pay with the currency, it looks like the Bitcoin is here to stay. At least until a better, cheaper and more reliable currency is on the market.

October 31, 2013

HR -LCP's Year End Process User Guide

Monitor - bi-weekly

a)      Monitor SAP website  bi-weekly https://websmp205.sap-ag.de/patches to determine if notes available SAP Component (verify system component level in production) and download or print appropriate notes  and review

b)      Coordinator will schedule recurring monthly meeting to discuss if  SAP notes for the same is available and the relative  support pack level which needs to be attained  for each component.

c)      If notes  are available Coordinator will schedule meeting with Basis and Testing teams  and submit a Change control board Engagement form for a Project Creation for the LCP's.

d)     SAP Component Leads will create a charm document for manual corrections


Continue reading " HR -LCP's Year End Process User Guide " »

BSI TUBS for US Payroll taxes - Tips and Tricks & Best Practices

Get latest tax updates and calculations affecting the payroll so that the respective payroll taxes are correctly deducted and calculated as required for the effective dates. For W-2 processing also if any changes have come in TUBS gets downloaded in BSI and thus calculates the correct reportable wages (taxes) for the year end processing and submission to IRS

Continue reading " BSI TUBS for US Payroll taxes - Tips and Tricks & Best Practices " »

October 27, 2013

End of life program for SAP systems

Typically End of life period for hardware will be 5 years and software will be 2 yrs (It may differ vendor to vendor and depends on organization policy). SAP EOL policy is different from other softwares. It spans 3 or more years for software and extend the support for hardware in coordination with hardware partenrs. SAP policy for End of Patch, End of Maintenance, and End of life (support) is available and it is well monitored with solution manager maintenance tool. For example EOL for SAP BusinessObjects XI 3.1: December 31, 2015 this is the date that patch support will end. It is scheduled to reach End of Priority-One Support on December 31, 2017. For End of Life - Support (Product) cases customers should explore the migration options with their SAP Sales Account Executives.


Continue reading " End of life program for SAP systems " »

The Hidden cost of poor project management

Because hidden costs are often unaccounted they often go unnoticed. Hidden costs can be material. Without them the complete picture of project costs does not exist, and therefore a P&L assessment of the project is flawed. Hidden costs are often social, emotional and human. It's much easier to price up how many iron girders are needed in a construction project than how many team meetings might be needed to ensure everyone understands the vision. These costs are difficult to quantify, but that doesn't mean we shouldn't try. Even if we really can't quantify hidden costs we can at least ask ourselves whether we have a problem with them, and then we will be more likely to do something about managing those hidden costs. We believe in adding value to our key contacts by sharing ideas, news and market updates we feel could be helpful to your daily business practices. Hope those can bring you fresh insight and new perspectives .

Continue reading " The Hidden cost of poor project management " »

KEY BENEFITS of Mobilizing HR

 Mobilizing HR applications can improve, employee retention, productivity and employee engagement. As the companies workforces become more mobile, the core functions that support these workforces must become more mobile as well. In the HR space, this means that a mobile employee must be able reap the benefits of employee self service capabilities without being tied to a hardwired desktop computer, or the manager should be able to view and act on important talent retention KPI's from his or her own mobile devices. Industry standard survey's provide the info that almost 40-50% executives and employees don't have sufficient access to mobile devices and can't perform their necessary jobs while they are mobile from their mobile devices


IT departments should be motivated to Mobilize and leverage HR data : The value of mobilizing HR data extends well beyond the HR organization. In fact, IT could see the most direct returns from HR mobilization. That's because the demand for qualified professionals is perhaps highest in IT organization these days and since more companies are looking for launching more IT projects .With mobile access to key HR data- like the development of top talent within the company and employee turnover rates, for instance- even the top brass management (CXO's who are on the move can have a much more productive conversations about  productive conversations about recruiting and retaining talent .

Continue reading " KEY BENEFITS of Mobilizing HR " »

Common Data Migration Pitfalls and How can we avoid them

Common Data Migration Pitfalls and how can we avoid them
Historically, many data migration projects have been plagued by risks and delayed go lives, resulting in costly budget overruns. The usual culprit is the data !!A frequently overlooked aspect of ERP deployments is the integrity of the data that the system delivers. Traditionally, many systems integrators implementing a new system prioritize the project

Continue reading " Common Data Migration Pitfalls and How can we avoid them " »

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter