Enterprise Role

My latest presentation on Enterprise Role Concept:
Enterprise Roles are the concept of creating the Authorization roles in SAP to align the business functionality more effectively and efficiently.

Moreover the integration of Enterprise roles, User provisioning and Workflow provide a scalable and agile platform for the the organization towards their current and future business requirements.
Quicktime (can view it in iPad; iPhone)

HTML:
http://mobiapp.onliemr.com/Umoja/roles/assets/player/KeynoteDHTMLPlayer.html

Future of IT as a department in an Organization

It would be a great mistake, if one can’t understand and prepare for the changes that are happening in the Information Technology part of the business and corporate world. These changes are happening in such a phase that is leading to a fundamental shift in direction of the way the job functions in an IT department is constructed, staffed and operated today. All these changes if not most of them are non-reversible in nature; means the shift is permanent and is not a temporary phenomenon. The technological advances combined with social responsiveness fuel these changes with a greater acceptance. Enterprises and organizations as always follow the individual consumers in realizing and adapting to these changes.

If an organization believes these changes are removing the traditional way of working and map it the elimination of the jobs would end up in a dead end. The reality is these shift demands new skills and new set of workforce economics. Here the cost is directly proportional to the talent density than the physical count of the employees.

As a two part series, let me articulate the changes and their effect on their traditional outlook of IT as a business unit.

• Platform architecture: One of the most significant trends that might impact an IT business unit is that the age of “viewing everything through an application lens is coming to an end.” Instead, platform architectures will be selected primarily to cope with soaring volumes of data and the complexity of data management, not for their ability to support applications. The tried and true relational database will not go away, but it will soon start to make way for other types of databases – streaming databases, for instance – that mark a significant departure from what IT departments and business users have relied on for decades.
• Cloud Computing: The focus will shift from simple infrastructure solutions to developing cloud strategies that deliver increased functionality and flexibility using a mix of public and private cloud-based application and platform services. While many challenges remain, cloud is nonetheless poised to change the face of enterprise computing. The adaptation to cloud from the application hosting perspective changes the traditional IT of running ‘on-premises’ to ‘on-demand’ mode; a completely different set off skill sets are required to manage and reap the cost benefits of the cloud infrastructure & applications. 
• Data Security: The fortress mentality, in which all IT has to be architected to be foolproof, is giving way to a security architecture that responds proportionately to threats when and where they happen.” As a result, the role of people in data security will decline, replaced by automated capabilities that detect, assess, and respond immediately. The IT becomes a hosted environment; a variety of automated, industry-tested applications will take over your ‘organization specific’ security, both at the infrastructure and application levels. Organizations have to be practical and evolve to the maturity of understanding the new-age threats and manage the changes in adopting and implementing the standards.
• Analytics: Companies that continue to view analytics, as a simple extension of business intelligence will be “severely underestimating analytics’ potential to move the needles on the business.” Among other failings, traditional BI does not take advantage of the wealth of unstructured data that is now available. IT leaders will need to work closely with business leaders to identify where analytics can be leveraged effectively, as well as the proper mix of services required to optimize analytics capabilities across the enterprise. The organizations have to turn their focus from a traditional transactional reporting to a world of agile, real real time and enable predictive analysis.
• Architecture: Information technology is evolving from a world that is server-centric to one that is service-centric. Companies are quickly moving away from monolithic systems that were wedded to one or more servers toward finer-grained, reusable services distributed inside and outside the enterprise. The goal: to decouple infrastructure, systems, applications, and business processes from one another. This approach is well have it’s best benefits, if the analytics is taken into consideration as explained in the previous step.
• User Experience: Today, business process design is driven by the need for optimization and cost reduction. Tomorrow it will be driven by the need to create superior user experiences that help to boost customer satisfaction. Great user experiences will require more layered approaches than what is typical today. As such, application design will be a multidisciplinary exercise: Typically handled today by IT architects and business owners, tomorrow it will involve optimization from the perspective of the process actor, with the emphasis on simplicity and on removing inefficiencies. The power of the mobile devices and the experience of the consumers with them will drive the expectations and will dictate the successful applications with satisfied users.

My Presentation at UNIFIL

Two weeks after the go-live of Umoja project, I was given an opportunity to present to the UNIFIL management, section chiefs and key users at the ramp up closure event. I had only two days and had to present the components related to user management and related topics. I decided to take the presentation into two segments one being the state of the union after the two weeks and segwayed to the main discussion point. I took a lot of time to take away the technical complexity of the topic and to provide a bigger brush stroke of the topic. I decided then to take the presentation to a different level and make the audience get involved with the topic. 
I was a bit nervous as the presentation room was shifted to a real & big meeting room that was equipped with a good set of presentation equipments. The day before I had to stay late night to make sure my Macbook pro works with the system. I was very thankful to my colleagues Jamal and his teammate for helping me late in the day despite their fasting. I had to make certain adjustments in the presentation to fit into the resolution of the big screen and two monitors on the sides. I also had to take my presentation on a memory stick if in case I'd some issues with the connectivity during the presentation time.
The day started well and the main discussion points were taken in the first session. As expected they over ran the schedule and that might have encroached into the later presentations. We took a break for 10 minutes and that gave me enough time to set up my MacBook and bring up the presentation on the screen. I had a rough idea of my narratives, but was confident to deliver. As the meeting started, I started with a small story to bring the group into the context of the content. I was very well aware that the first few minutes would be crucial to get their interest in what I'm going to say, keeping in mind the standard deviation of the exposure the my topic with the audience. I took the narrative as a story.
Other than a little hiccup at the initial stages with the mic, everything went well. Within few minutes, I was getting more and more confident, as I can see the faces of the audience bright and involved. I was able to  freely look into all directions during the delivery. I think it took around 31 minutes and when I wanted to finish, I thought of relating myself once again. I decided to say that my experience of changes in perception about UNIFIL from when I landed and till date and relate it to their experience with the new application. I finished with a big 'Thank You'; as I look around and waited, there was a bit of silence; then a burst of applause.
I felt very happy as everyone in the audience came to be, hugged and told me that the awed by the presentation and the clarity of the topics discussed. They were extremely generous to praise me all the way. 
The only thing I did not plan was to record the presentation; I had to reconstruct it later as there was a lot of interest generated by word of mouth. Here it is and let's see how you feel about it. Click on the image below:

Role of IT team in UMOJA implementation

SAP is an application that took both business and IT world by surprise during late 90s and early 2000’s. The time was too short for these silos in an organization to own this and manage it. However the big six auditing firms quickly recognize the importance of this application and the impact that this was going to make during the Y2K issue was threading big corporations; forcing them to look for a sustainable alternative. They branded the IT solution a reengineering agent and started selling it to the CIOs and CFOs. Even though this happened decades ago, the mystery still remains, especially when it comes to the SAP implementation project. One factor that needs to be considered in this context is that SAP is an application similar to Microsoft office, but needs to be configured and enhanced to I fit to run your business better. There exists responsibility on all parts of the organization to carry it through equally and unequivocally.

In a typical situation, the business and IT usually end up having this conversation & mindset.

BUSINESS to IT: “I want this, this and this from our SAP systems. Go away and make it happen then tell me when it’s live. PS -- I’m not available to spec it out … I’m too busy to test … oh and it’s not coming out of my budget. And I need it tomorrow.”

IT to BUSINESS: “Sounds great, but you must have me confused for a mind reader. Am I supposed to have a crystal ball that magically predicts your needs and anticipates every issue before the solution goes live? Seriously, I just need to know where to start. My team and I are too busy to troubleshoot this entire project from scratch, only to find out you wanted something different. If you want me to take responsibility for its success, you need to give me the process requirements and insights we need to succeed.”

Does this sound familiar? While the dialogue above has been exaggerated slightly for dramatic effect, the basic scenario it describes is consistently played out at countless companies struggling to establish ownership and best practices for their SAP systems and including our own UN!

The problem here is there’s no clearly defined ownership. But what’s the solution? In order to get there, let’s take a look at the backstory. How’d we get to this point in the first place? We need to understand the perception and the actions following that

Many businesspeople make the mistake of considering SAP applications strictly as an IT domain, consisting of various programming tasks. (When those tasks aren’t automatically completed without their oversight, they think of IT as an obstacle to SAP success.)

IT people, on the other hand, don’t understand why the business departments won’t give them the information they need to make the organization’s SAP systems function efficiently and effectively. They see the businesspeople as the obstacle to SAP success.

The Solution:

The truth is somewhere in between. When it comes to optimizing our SAP systems, ownership should come from the top down. This means the DMS and the business experts should drive the entire implementation and optimization process through clear and comprehensive communication of all business requirements and parameters. When the business side of the organization owns the data and transactions, it has a vested and actively maintained interest in how the system processes fulfill their business requirements, including: master data, applications, transactions and reporting.

Where is IT’s role then? IT should be an enabler for the processes above. While ownership of the overall SAP systems belongs to the businesspeople, IT should be responsible for the infrastructure and architecture of the system. This means taking the requirements and data supplied by the business side and translating them into functional solutions that fulfill the company’s needs. IT also holds a great value addition to the process by keeping the application on the cusp of the technology curve and makes it adoptable to any new technological adoptions

One of the biggest mistakes most businesses make when it comes to their SAP systems is to treat them like a function of the IT department. It’s a fact: you can’t spell “profit” without IT. Of course, when implementing any IT business solution, you incur the overhead and business costs of supporting and maintaining your new system. And in practice I’ve seen the technical staff understand and adopt to business functions more comfortably than the other way.

When it comes to SAP implementation and optimization, you need to assess the costs of maintaining and supporting your new IT solution in terms of what it means for your business.

As a general rule, it helps to remember SAP (and IT in general) should be a function of your business, not the other way around. Only then will you realize the full value of your SAP system. The better the SAP implementation and optimization processes are at supporting and enhancing your business, the more value and ROI you reap.

 UNIFIL: My thoughts on Go-Live

On July 1, 2013 Umoja went live; a bust of euphoria and happiness all over; I was observing that silently and wondering the whole process. I've been in similar situations; at least a dozen SAP implementations of similar nature (global rollouts) and this one seems to be a bit different. The go-live seems to be perceived that it went too well than it was in reality. I as cautious and at the same time trying to write down the key success factors for such perception.

First, the must need for any huge re-engineering projects, the UNIFIL top management had a great involvement and took a great deal of interest in transforming the commitment to every member of the team.

Second, the IT infrastructure was well built, managed and had a robust support infrastructure and knowledgable staff. Even though the support structure was not there for the SAP implementation; the commitment of the IT team in building the iNeed infrastructure, created the perception of the continued support structure and made the users confident and comfortable

Third, the training that the deployment team gave to the local process experts and end users to get familiarized with the live system.

This can be articulated as a base for the support system in three phases before, during and after SAP implementation. My take on the success of SAP project is not only how well we design and build the solution, but on the support structure we architecture and deploy!      

Ensuring the long-term success of your SAP implementation requires careful planning, preparation and support. From the moment we decided to integrate SAP into our business to long after your new business management software system goes live, having a team of experts (like me!!), is the key to sustaining success and getting back to business as usual.         

One of the biggest mistakes most organizations make when it comes to SAP support is to expect a standard distribution curve with just one spike when you first go live or put a significant piece of new functionality live (like Umoja Extension . They assume they can simply manage those increased support requirements and then stabilize from there. That assumption usually results in the removal of post-go-live SAP support at the exact moment when it is most essential.

The reality is every SAP implementation consists of TWO support requirement spikes and, without fail, the second is nearly always bigger than the first.

The reason is simple: at the moment your new platform goes live staff members are performing with a safety net of extended support coverage in place. They are following a script, learning the interface and starting to gain confidence. In effect, they are moving through the first stages of the learning process:

1.    Unconscious Incompetence -- They don’t know what they don’t know. At this stage of the learning process, your employees may not even recognize the benefits of your new SAP platform. They are a blank slate ready and waiting for input.

2.   Conscious Incompetence -- This is the stage at which users begin to understand exactly how much they don’t understand about Umoja and how that knowledge will benefit them in their roles. Mistakes here are common and, ultimately, helpful in furthering the learning experience.

As go-live Umoja support scales down and users start to gain more confidence in their ability to navigate the new system successfully, they move from the second, to the third and ultimately fourth stage of the learning process. This usually results in the second spike in SAP support requirements because your employees are moving away from the script and they have the confidence to explore capabilities and ask more complex questions.

3.   Conscious Competence -- By now, users have started to form a solid understanding of how SAP works with and for our business. They have begun to form the skills they need to take full advantage of the new features and functions at their disposal.

4.   Unconscious Competence -- At this point, the necessary skills have been developed to the point where they are becoming second nature.

While every SAP implementation is different and requires specialized support strategies, recognizing these phases exist allows you to better prepare and budget for them.

When reducing the Umoja support coverage, it is also critical we make it event-driven rather than time-driven. For instance, some business processes only happen once a month, so you need at least 60 days before you can accurately predict user behavior and overall system stability.

We should not make the mistake of eliminating or scaling back your support resources just because implementation is complete. In fact, in order to ensure complete Go-Live Satisfaction, it’s a good idea to increase the availability of those resources post-implementation.

My next section of this blog is how core IT staff can support SAP applications...expect soon

To Maintain the User ->Company details:
You go to the company address maintenance via transaction SUCOMP. You can assign the company address in user maintenance using the relevant pushbuttons.

How to suppress the POST button on a FI transaction

Copy the Sample Function Module(SAMPLE_INTERFACE_00001140) to 'ZSAMPLE_INTERFACE_00001140' and put the below code:-

IF sy-tcode = 'FV50'.

t_exctab-okcod = 'BU'. " do not allow to post

APPEND t_exctab.

ENDIF.

(If you want to disable this post option for multiple transactions, just maintain them in a custom table. Instead of IF Sy-tcode = 'FV50' just read from this custom table.)

Go to transaction FIBF and then Goto Settings->Products ->of a Customer. Press Execute.

Click on New Entries and create a new product ZPOST, give a proper description , Select the check box and save.

Go back to the FIBF first screen. Go to Settings->P/S Modules->of a customer

Click on the new entries Enter the event as 00001140, Product as ZPOST and Function Module as ZSAMPLE_INTERFACE_00001140. Save.

Now when you execute FV50, you will not see POST option on the application tool bar as well as from the Menu.