Muralidhar Lanka

SAP Implementations - DO's and DON'Ts

2019-08-11T02:50:00.001-05:00

Small and Medium Sized Businesses (SMB) and organizations that have outgrown their home-grown ERP's and spreadsheets should undertake the ERP journey sooner than later for various reasons such as process optimization, scaling their business processes, etc... The imperative for maintaining a lean IT team, competing IT projects and other factors require an organizations to engage with an implementation partner that can stay with them through the ERP leap. In this article, I am going to address a few Do's and Dont's when engaging with implementation partners (most of these suggestions stay valid even if the implementation is done with internal/contract staff).

Internal SME's and Management Commitment:

The journey must start here! Your SME's have a full time job - you must be able to identify this CORE TEAM of business SME's that will be committed to staying on top of their project tasks and there should be absolute commitment from the Senior Management Team to make this happen. Whatever it takes to free up 30-70% of their time at various phases of the project should be done. Not keeping this focus is the prime reason for the failure or under delivery of many ERP projects.

Since the organization's priorities keep changing with customer demands, it is very easy to lose focus on the implementation project and develop a tendency of "we will deal with this later", which invariably comes back to hurt the project or post go live user adoption. New customer orders received, people turnover, projects that are running in parallel, changing business processes during the implementation process - are all factors that should be taken into account and evaluated at an pre-established rhythm throughout the project timeline.

The need for a Steering Committee formulated with members from the Senior Management Team cannot be overemphasized here. A committed Steering Committee is required to make the right calls on tough situations during the implementation.

Onsite / Onshore / Offshore Resources:

Having a team of onsite resources / consultants is perhaps the most intuitive staffing approach for an ERP implementation. However, in a cost-sensible, "connected" world, there could be other options. A mix of onsite / onshore / offshore resources can bring an optimized value for the implementation if it is managed well. Here are a few things to consider with this approach:

Ask the implementation partner to provide the names and profiles of all the resources that will be working on the project.
Interview most or all the resources, regardless of whether they are onsite / onshore / offshore.
Ensure that the internal team develops a healthy and regular working relationship with the respective counterparts from the implementation partner.
Ask for a weekly load chart for every resource from the implementation partner. There will be times in the implementation project where some of the resources may not be needed full time. Likewise, the PP (Production Planning) Onshore / Offshore resource may not be needed until some of the other configuration is in place, but there should be an onsite resource at the beginning of the project for requirements gathering. If the implementation partner has people and experience in managing projects at this level, it could be to your cost advantage.
Do not hesitate to negotiate with the implementation partner regarding the skill sets engaged in the project. Normally, implementation partners will work with you to have the right resource mix that can work well with the organization, but many times, you need to ask!

Project Management and Governance:

It would be ideal to have a Project Manager from the organization as well as a dedicated Project Manager from the implementation partner to make sure that tasks keep moving on both sides. It is extremely important for your internal IT expert (s) involved in the project and the Project Managers to be in a great working relationship to resolve issues in an effective manner. There should not be a hesitation to escalate unresolved issues, especially organizational issues, to the Steering Committee to seek timely resolution. In general, it is common to identify organizational issues during ERP implementations that are representative of process bottlenecks, inefficiencies that have not been identified previously or have been neglected or people that are in love with archaic practices. If these issues are not resolved, they will in most cases result in project failures or poor user adoption in the respective areas.

The Enterprise Architect / The Guardian:

If the organization has on staff one or more qualified Enterprise Architect (s) that have a grasp on all the organizations business systems and the integration between these various systems, Great! The ideal Enterprise Architect should have experience in multiple modules of SAP, other related systems such as CRM and SRM, Business Intelligence, an optional PLM (if the organization requires it), document / content management systems, middle-ware and also be adept at managing vendors and evaluating different software systems with little or no guidance. If you have someone on your team with this kind of skill set, you should make sure that they are closely engaged in the implementation project. If you have someone with a subset of these skills, you should certainly consider hiring someone to complement and provide complete coverage for this skill set full time or part time, depending on the need. Preferably, this resource should not be from your implementation partner, so that they can completely represent the organization and be a true Guardian! This Enterprise Architect or The Guardian role could bring several failure points to the team's attention before they become realities and provide with valuable suggestions to make your implementation a great success!

*********************************************************************************

This does not cover all the aspects of an SAP (ERP) implementation, but could be a good start for someone that is starting fresh or a refresher for those experienced.

*********************************************************************************

Change Management for ERP Culture

2012-01-10T22:08:00.000-06:00

Introduction
Change is tough! Period. The number of partial or complete ERP implementation failures caused by a lack of proper strategy for change management is amazing. When organizations implement an ERP system, there is invariably resistance from almost every level in the organization. There could be a variety of reasons for this resistance including employee job security, the fear of the unknown, a general aversion to change, a lack of dynamism in the organization’s culture (the organization has never re-engineered its business processes), a lack of skills to learn new systems or ways of doing things, a lack of appreciation of the gains, personalities
or a combination of these. This article looks at some of the key aspects of managing change due to an ERP system implementation in an organization.

Management Support. An ERP is not a single-person, single-team or one-department system. It’s a combination of systems and processes with elaborately detailed integration between these systems and processes. Regardless of which ERP, an ERP more or less literally touches each job role within the organization. Without complete appreciation and support from the senior management of the organization, the success of an ERP implementation is almost bound to fail. Therefore, it is of utmost importance for management to spread awareness across the organization about the priority and significance of the implementation to make sure that there is due diligence of contribution at each level and throughout the process of implementation. All that begins well ends well – this statement is very much valid in this context and if it doesn’t begin well, it doesn’t end very well either.

Debunk the "Golf-course" Myth. Whenever there is a new system or tool introduced in an organization, there is typically the view that the decision was made in "golf course" without due diligence in weighing the capabilities of the system. Although there is the occassional exception that such a decision could have been really made in a "golf course" fashion, it is truly an exception. Typically, whoever spreads these words does not really understand the true potential of an ERP system as an integrated set of systems and processes, but rather tend to view things from a specific "technical silo". Propagators of such a message in the organization could really cause damanage to team morale and if they are strong enough influencers, could cause an implementation failure. It is imperative for the management at all levels to work with their peers and teams to promote a positive appreciation for the new system taking a wholistic view and explain why it is important to make some compromises at a micro level, in view of the macro level benefits brought about by the new system.

Adopt the Adapters, but Manage the Others. It is important to identify and nurture the new technology adapters in the organization early on in the game. However, it is also important, and in some cases, it is more important to properly manager those that don’t get in the bandwagon in the early stages. If not managed properly, they could become show stoppers or may slow down the process at every step going forward. It may be necessary to persuade them by spending more time with them, listening to their points of objections, assign more responsibilities and engage them in the decision making process, etc… Nevertheless, the changes in job roles and responsibilities must be properly communicated to all stakeholders early on in the process.

While grooming the adapters in the new systems, it is also important to avoid creating political groups. This is bound to happen to some extent in every organization, especially between the BPO’s and the rest of the user groups, but it should be dealt with and minimized right from the beginning. If not dealt with, it will create pessimism in the organization, result in low employee morale, and may cause process inefficiencies down the road.

Complementary Training. There could be complementary training necessary for many employees to enable them to perform their new job role more efficiently and make the transition smoother. It could be sometimes a more formal MS Office (e.g. Excel) training. Depending on the person’s role in the organization, a combination of skill and/or responsibility orientation (e.g. role of a purchasing agent or a project manager) could help the employee approach the new system with a more positive and open-minded perspective than that without such academic training. Especially, in organizations that have grown from boutique firms through mergers and acquisitions into bigger organizations or became part of a bigger organization, such reorientation in terms of job roles and responsibilities becomes imperative. If not done properly, the employee may never be able to own the new system.

Emphasize Job Security. Although it might result in the elimination of certain redundant job roles in the organization, an ERP is intended to give organizations a competitive edge in terms of efficient business processes and integrated information processing, so that the organization could focus its energies in improving effectiveness and innovations rather than chasing its own tail to keep operations running. Moreover, early participation and contribution to the ERP implementation will nevertheless make the business user more valuable to the organization. By building experience and expertise in the new systems, the business user is bound to become indispensible for the organization. Additionally, in today’s competitive career world, an ERP system certainly adds value to a business users profile and improves his/her marketability. It can be easily seen on job boards that employers tend to be preferential to business users with experience in systems than those that do not have the experience. If this aspect is highlighted to the employee, it would certainly prove to be a morale booster.

End User Training. Make no mistake. Whatever training approach is adopted (e.g. train-the-trainer), each person that fits into one or more ERP job roles must be trained to understand the width and breadth of his job role and handshaking points with other departments and/or job roles. Additionally, it is also important to cross-train people on relevant and adjacent job roles so that brain drain and attrition could be efficiently dealt with.

Workforce Stability. One of the most important aspects during the implementation and stabilization phase of an ERP system is workforce stabilization. Almost no organization can sustain aggressive and constant changes in management structure or attrition during the implementation and stabilization phase of an ERP system. Other than those changes needed for the implementation itself – such as redefining job roles and responsibilities or reorganizing certain departments, no major organizational changes should be entertained. This will seriously damage employee morale and provide inconsistent and often contradicting direction to staff leading to nothing but disaster.

The ERP Consultant. The ERP consultant should play a key role in the whole equation, because the consultant is not only responsible for configuring and testing the system according to the client’s needs, but he/she should act as the liaison between stakeholders across the organization to make sure that process flow is properly defined and ensure proper handshaking between interdependent departments. When people ask the question, “why are these guys paid so much?”, this could be the single reason why an ERP consultant is and should be paid the premium dollar, if any. The configuration of the system can typically be completed by an ERP business analyst, but the application of the “soft skills” to accommodate for different viewpoints, yet make sure that the industry best practices are provided to the organization to give them the competitive edge through the implementation of an ERP system falls on the shoulders of the ERP consultant.

As you can see, this is by no means a comprehensive change management guide for ERP implementations, but the intention is to highlight the most important aspects so that a project team going into an implementation could go in with the proper frame of mind into the implementation. I truly wish to welcome discussions on this topic from all you experts with industry experience.

Project Based Manufacturing: Make-to-Order

2011-12-16T14:24:00.001-06:00

Introduction
As opposed to make-to-stock production, which is geared towards stocking finished products to meet a forecasted demand by customers, make-to-order production is driven by the receipt of a specific sales order from the customer. In make-to-order production, customized finish products are assembled using more or less predefined production processing. Make-to-order business processes cover the middle ground between the two extreme cases of production - make-to-stock and engineer-to-order. The demand to the plant floor for the finished product in the case of a make-to-order product indicates the general production area, where various variants of the product are made.

In case of make-to-stock, the same finished product is created repeatedly using exactly the same sequence of steps. Automotive manufacturing is an example of repetitive / make-to-stock production. On the other hand, engineer-to-order production represents a case where each finished product follows significantly different production/assembly processes. More than likely, the company is making the exact product for the first time with a lot of attention to detail required. The construction of a turbine or a new aircraft is an example of an engineer-to-order production. In the middle, make-to-order represents the form of production that uses similar procedures to produce the finished product each time, however, the exact steps are not known ahead. A company like Dell, selling custom configurations of computers or an aerospace tooling supplier is an example of make-to-order production situations.

It is possible to process the different manufacturing scenarios using different sets of business processes and transaction sequences in SAP. The sections below provide an overview of the assembly processing business scenario in SAP using Project Systems (SAP PS) to complete make-to-order production. The explanation is specifically aimed at using a network order to complete the physical assembly of the finished product, together with a Work Breakdown Structure (WBS) for measuring profitability of the project (sales order) as a whole.

Procedure
The process starts with the entry of a sales order in the system upon receiving a PO from the customer to deliver a certain quantity of the finished product. The following is a checklist of the things that must be set up in the system before the process could work:

1. A standard network template: the network template forms the basis for planning network activities in the operative project once it is created. Careful thought must be given in the creation of this template to make sure that the template covers the most common variant of the processes to assemble the finished product. The template should also include a standard BOM of the material components that make up the finished product. Note that material components cannot be assigned directly to network activities in a standard template – they can only be assigned by means of creating a standard BOM and then transferring materials to the appropriate network activities.

NOTE: If needed, create multiple standard templates covering each of the known variants of the finished product.

2. Material Master: The material master representing the finished product is used in the creation of the sales order item, which triggers the automatic creation of the network order along with the project/WBS structure. Additionally, there are settings in the material master that must exist in order to indicate to the system that a network order should be created to assemble the finished product. This indication is driven by the “requirements type”, which is determined in the sales order in one of the two ways: a) the system first looks to find the requirements type through the MRP group and strategy group assigned in the material master MRP views; b) if it is not found using option a, then the system tries to find it using the combination of the item category group in the material’s sales view and the MRP type.

3. Requirements Type and Requirements Class: The requirements type determined in the previous step is assigned to a requirements class. The requirements class has the settings that control the creation of a network order of a specific order type, along with the management of special stock (project stock), etc…

4. Assignment of the material master to the standard network template: the final step in the process is to assign the material master for the finished product to the standard network template created above in a mapping table (transaction CN08). Also, assign the standard WBS that should be used in the creation of the operative project structure associated with the network order.

Business Benefits
Once the above set up (configuration and master data set up) is complete, a new sales order created using the material master and/or the item category to derive the correct requirements type result in the automatic creation of a network order that is assigned to the project/WBS structure. When this process is complete and the sales order to project/network link is established, the following are some of the business benefits that can be realized:

1. With the strong integration of the various parts of the order – such as order processing (SD) and order execution (PS), changes in one area can be immediately seen in the other. For example, if the customer required delivery date is changed, the network order is immediately updated with the change. Similarly, if the project delivery date cannot be met because of capacity bottlenecks, the resulting new proposed delivery date can be immediately seen in the sales order. This will help a great deal in terms of reacting to the result proactively to take corrective actions on either end.

2. If the cost management is left to the project (project valuation), the cost control and evaluation can be managed at a more detailed and complex level.

3. Since the sales order value and billing flow into the project WBS element, the costs in the project can be easily compared with the revenue flows to determine profitability of each delivery to the customer on an individual or collective basis.

4. Further processing such as the calculation of POC (percentage of completion) is built into the SAP system through the usage of Results Analysis and subsequent settlement to FI/CO.

5. Profitability Analysis can be performed on all customer orders by additional settlement of the RA values to CO-PA. Based on configuration, very insightful reports can be developed to evaluate profitability by order, customer, sales area, etc…

It can be clearly noted that the above explanation leaves out a good deal of technical content in terms of configurations, user-exits and minute details. However, the idea is to highlight the business benefits of the process than to provide all the technical details. If you have questions or want me to expand on specific areas, please do leave your comments or send me an email: lanka5255@gmail.com.

SAP for Small and Midsize Companies

2011-12-01T22:29:00.001-06:00

Introduction
Invariably, businesses growing from boutique firms to sizeable businesses always struggle with their teams becoming more and more disconnected from an overall business process flow point of view. It's very easy for companies to fall into this trap in the middle of aggressive growth and consequent demands on delivering to customers - before the management realizes, is is very likely that the company has developed information silos and disconnected departments, resulting in organizational inefficiencies hindering further growth and a reliable profitability analysis. This is where business management software solutions come into the picture to rescue. There are a wide variety of sotware vendors providing business software solutions, but
my focus as a veteran SAP consultant is going to be on SAP and their offerings.

With over 35 years of experience in helping customers with business software, SAP's increased focus and investment in solutions for Small and Midsize enterprises provides great value proposition to the businesses in this space. Although SAP has been working on these solutions for a few years now, there was a small tide back in the 2006-2007 timeframe, which was severely subdued by the market recession in 2007. However, there has been a lot of talk again since 2010 about these solutions and the European and Asian markets are already sailing big through the tides as it seems. It's good timing for the US markets and businesses to pick up on this wave, because the solution has already seen some ups and downs and there is a lot of functionality built into the system that will give small and midsize companies to get a kick-start on organizing their business processes around a matured business software system, especially giving due consideration to the fact that SAP has extensive experience built under the belt in this area. Without hype, let's get into the details of these offerings.

Solution Proposition
SAP provides a full range of solutions for small businesses and midsize enterprises ranging from on-premise to on-demand solutions. The sections below are intended to provide an understanding of the product suite at a high level. You should determine the best solution for the type and size of your business by engaging with SAP or one of the channel partners.

SAP Business One
SAP Business One is the solution for small businesses. Although there are partner companies offering solutions on the cloud for Business One, primarily this is a completely on-premise solution suite, meaning that your company will host and manage the software. The software runs on Windows Server and Sequel Server database platforms resulting in affordable investments into the IT infrastructure to support the software. Although there are no hard limits on the number of users that the solution is applicable for, this solution is most applicable to businesses that have a maximum number of around 30 end-users that would use the system on a daily basis beyond things like time entry. SAP gives you the ability to choose the functionality your organization needs and keep adding to the suite as your business need grows. SAP provides complete business functionality around the following business processes:

Accounting and Financials
Sales and Customers (Integrated CRM functionality)
Purchasing and Operations
Inventory and Distribution
Reporting and Administration (Reporting complete integration with Crystal Reports)
Software Development Kit for easy software extensions

This solution is available with more than 14,600 customers with 40 country specific configurations. There are over 1350 certified partners with over 350+ industry specific solution extensions.

SAP Business ByDesign
Business ByDesign is a cloud-based solution, meaning that SAP will host the software on their servers and manage all the upgrades / maintenance for you. The solution footprint can be expanded to grow with your growing business needs by scaling up the availability of software. It is intended provide customers with a world-class business software system without the extensive IT expense required for it.

SAP Business All-in-One
All-in-One is essentially SAP ERP with deep industry best practices built into the software. It leverages the breadth of functionality available in the SAP R/3 / ERP suite, but tailored to specific industries with micro-vertical solutions. This solution is intended for customers with less than 2500 employees. These are a few facts from SAP:

The software is available with over 10,000 customers and 50 country specific configurations.
There are over 950 certified partners with over 650+ solution extensions.

SAP has a strong ecosystem with significant breadth of solution and geographic coverage through their partner network that will make finding the right resources to implement or improve your SAP solution a better possibility. In addition, SAP's increased concentration in this area propels significant product enhancements to improve the functionality built into the software as well as the availability of industry-specific extensions to bring the best business processes to your doorsteps.

Please feel free to respond to this blog with your comments and uggestions.

SAP CATS for Contractor Labor Payments

2011-12-01T22:23:00.001-06:00

Payment of contract labor services is often a cumbersome process in many organizations. The reason being, there are various stakeholders involved such as the managers / supervisors that need to approve timesheets, the purchasing department that needs to manage the PO's, AP paying the vendors, the vendors submitting the invoice and the contractors themselves, that need to keep one or more versions of their timesheets, depending on the client and vendor requirements. It is very common for companies to spend significant dollars to set up something like a vendor portal or time entry portal for contractors to achieve even a semi-automated system. More often than not, even a minor hiccup in the whole process,
such as a contractor entering the wrong number of hours or entering hours on a holiday could cause a lot of communication and trauma to resolve issues.

In SAP, the combination of SAP Cross-Application Timesheets (CATS), Service Entry Sheets (MM-SRV) and MM-Purchasing with a little bit of Human Resources (HR) infotype maintenance provide an easy solution for this problem. CATS is used in SAP for several time entry scenarios including time entry against projects, networks, CO objects, work orders in Plant Maintenance (PM), Payroll time recording, etc… or a combination of these. In addition to these, it could also be used to have a contractor enter time against a service line item on a purchase order. Since it is not feasible for me to provide screenshots, I am going to layout the process here to accomplish this configuration. I will try to update the post with screenshots when time permits me to do so.

HR Set Up
To avail this functionality, it is important to have the HR functionality activated with bear bone HR infotype maintenance to define a personnel record for the contractor, fill out info types 0001 (Actions), info type 0002 (Organizational Assignment) and info type 0035 (Timesheet Defaults). The following information must be filled:

· Personnel number.

· Employee group / subgroup (IT: 0001)

· Personnel area / subarea (IT: 0001)

· Cost Center (IT: 0002)

· Vendor Name (IT: 0035)

· Purchase Order (IT: 0035)

· Purchase Order Item (IT: 0035)

· Activity / Service master number (IT: 0035) – this is the service master number used in setting up the PO line for this contract resource).

NOTE: Please note that some of the information maintained in these Info types needs ongoing maintenance by the HR personnel to keep the records up to date, for example, PO/Item number.

CATS Set Up

A data entry profile must be created that allows users to enter time against purchase orders. Depending on the need a release approval should be set up in the data entry profile. Timesheet defaults should be configured such that the purchase order, item and activity number are copied from IT: 0035 from the user’s personnel master record in HR.

MM-SRV Set Up

One or more service master records must be set up in MM-External Service Management component to represent the types of services rendered by the contract labor force.

MM-Purchasing Set Up

Service Order type purchase orders must be set up for the contract labor to represent the organizations issuance of PO’s to the corresponding vendors. A service line item must be set up under each PO corresponding to the service number set up for the personnel master record in HR IT: 0035.

Additionally, if the organization uses ERS (Evaluated Receipt Settlement) with vendors, the corresponding vendor masters could be configured for ERS payment to gain more automation to the payment process.

The following are the process steps from time entry to vendor payment.

· Employee (contractor) enters time using the appropriate data entry profile using transaction CAT2 (the data entry profile can be assigned to the user’s user profile). User confirms time has been released by going into transaction CADO.

· Supervisor / manager approves contractors time using transaction CAPS. The supervisor should set up his/her own variants for their responsible employees so that they can review and approve their time on a single screen. NOTE: The system could be configured in such a way that the managers approval is the single point of approval and approval means payment to the vendor for the approved hours.

· Run transaction CATM to transfer approved hours to the MM component, which automatically creates a Service Entry Sheet (SES) for the approved time against the PO line item set up for the contractor.

· Purchasing agent runs transaction ML81N to accept the SES. NOTE: If the organization determines that the manager / supervisor approval could be treated as payment approval, a simple ABAP program could be set up to automatically accept SESs created through the CATM transaction.

· At this point, a GR (Good Receipt) is posted to the PO in SAP.

· Depending on the invoicing mechanism in place in the organization, an invoice can be generated in the system against the PO, which will be paid by AP (Accounts Payable) based on payment terms from the PO/vendor master record.

NOTE: Any changes to the timesheet or the approval before SES acceptance are automatically updated in the system. Any changes after the SES approval need to be manually corrected in MM-SRV/MM-PUR in coordination with the manager / contractor.

There are additional discussion points such as the account assignment category of the PO, cost accounting for the time entry, etc…, which should be considered when implementing the solution after discussions with the appropriate departments.

Please feel free to provide your comments or suggestions.

FI Document Parking using SAP Workflow

2010-02-09T14:20:00.013-06:00

Compliance with the journal entry standards set forth by company audit teams and Government agencies requires that several documents in financial accounting (FI) require a review and approval before they are posted in the system. The SAP FI Document Parking functionality provides the framework for subjecting an FI document to an approval process using the SAP Business Workflow component, along with several possible enhancements to the process per customer requirements.

The document parking functionality provides the necessary configuration options to determine whether and how many levels of approval are required for a given document using the FI doc type and the amount. Therefore, it is possible to require only specific doc types to go through the review / approval process and a doc type and amount combination to determine the number of levels of approval required for an FI document.

The process begins with the accounting clerk parking the document. Once the document is parked, it is sent to an approver for authorizing payment amounts, so that the amount can be approved for release. Next, the document may be returned to the clerk for completion. Finally, the document is sent to the person responsible for account assignment approval. Once it is released, workflow triggers the document for posting in the background. The following graphic helps explain the process:

The procedures described in this article are the standard SAP processes. I am also going to provide pointers to some of the customization opportunities that would provide the required flexibility for client specific requirements at the end.

Basic Workflow Setup

The release workflow process is initialized with the FIPP.CREATED event raised when the FI document is first parked. This event triggers the standard workflow WS10000051, which provides the framework for the entire workflow process. For example, the release sub-workflow are determined at runtime during the execution of this workflow based on configurations set up as explained later in this article. Once the sub-workflows are executed without error, this workflow also has the task that posts the FI document in the background. The event linkage for this workflow must be activated for the FIPP.CREATED event using transaction SWE2.

Release Approach

The standard system provides two ways to release the document, either or both of which can be implemented:
- amount release; and
- account assignment release;

Amount Release
Amount release is triggered when the document is first parked. The standard system provides three different sub-workflows for amount release - WS10000052, WS10000053 and WS10000054 respectively for one, two and three levels of approval for the document. You can define your own custom sub-workflow and assign it in the configuration settings as explained below. One point to note though is that the custom sub-workflows should have the same interface as the standard interfaces.

Account Assignment Release
Account assignment release is triggered when the document is completed. The account assignment approval is valid for all organizational objects such as position, job, and organizational unit that are assigned to the release step. You can assign persons responsible for cost centers in Organizational Management (HR) – then, the person responsible must approve all the documents created with account assignment to the cost center. If the document is approved, it is posted in the background. If it is rejected, it is sent back to the clerk to make modifications. The account assignment sub-workflow is specified in the configuration step to define the workflow variant. You can define your own custom sub workflow and assign it in the workflow variant, but the custom sub workflow must have the same interface as the standard sub workflow WS10000055.

Configuration

The following graphic shows the IMG path for the entire document parking functionality:

Workflow Variant
The key to the configuration is the definition of the workflow variant, which, after creation, is assigned to the company code for which document release is to be implemented. The workflow variant determines whether document release is required and the amount limit after which document release is required. Any document below this amount limit will not be subject to release. Additionally, the workflow variant defines the sub-workflow to be used for the account assignment release (account assignment release is explained later). The graphic below shows the workflow variant:

Release Approval Groups
When dealing with vendor / customer postings, release approval groups allow to group release procedures (the number of releases, doc types, etc…) together. The release approval groups defined in the IMG are then assigned to vendor / customer master records. Subsequently, when an FI document is created against the corresponding vendor / customer, the system copies the release group information into the document and determines the document release procedure based on configuration for the release group. However, this article only deals with FI-GL documents, so we will not be discussing those features here.

Release Approval Paths
The release approval paths provide a way to combine FI doc types and release approval groups (if they are configured) to determine the release procedures. The following graphic shows the assignment of release approval paths to doc types and release groups:

Release Approval Procedures
The release approval procedure determines the sub-workflow to be used for amount release using a combination of workflow variant, release approval path and amount. One of the three standard sub-workflows for amount release or a custom workflow could be assigned in this configuration step.

Users with Authorization to Release
In this step, you will assign organizational objects such as a job, position, organization unit, etc… to the combination of the workflow variant, release path, release level and amount. This will authorize all the users assigned to the organizational object to release the FI document. Alternatively, you can determine the agent to send the FI document work item using workflow customizations. This will mean that an agent determination by organizational unit or an agent determination rule with a function module is implemented in the workflow. This method is especially useful if you do not have HR-Organizational Management completely implemented.

Release Process Outlines

The following screen prints are from a workflow implementation where only the amount release is configured in the system. Once the document is parked a work item is received in the approver’s Inbox:
Upon executing the work item, the document is displayed with the options to release / reject the document:
Once the document is approved, it is posted in the background.

Relevant Customization Opportunities

User-Exit EXIT_SAPLF051_002
This user-exit is useful when it is required to conditionally trigger the release workflow upon parking the FI document based on pre-defined conditions. This user-exit receives the BKPF and BSEG data structures in the interface, therefore, it provides a wide range of options to conditionally control the triggering of the workflow.

Business Transaction Event (BTE) 1140
When using the workflow process, SAP security does not prevent posting the documents directly in the system without having to park them. It becomes almost essential to prevent this from happening by implementing the BTE 1140 to disable the POST option on the document posting transaction screens, so the user is mandated to park the document and go through the workflow process if it is required.

Accrual and Recurring postings in the FI-GL space require special handling and custom workflows, because SAP at the level of ECC6.0 does not provide a mechanism for these documents to be parked and posted using the workflow process. Hence, the business objects for which create events must be raised are different and there are no standard workflow templates provided for them either.

Please feel free to let me know if you would like to explore the possibilities in this area.

Project as an Investment Measure

2010-01-19T14:18:00.014-06:00

Projects are often used as investment measures in the Investment Management component to manage the accounting and controlling aspects of either

a) Investment initiatives to produce long-term fixed assets for the enterprise; these have to be entered in the balance sheet as Asset Under Construction (AUC); or
b) Other measures for which you want to plan, collect and oversee costs

Investment measures are represented in the system as internal orders or WBS elements, possibly with an AUC assigned to them. The flow of data between Investment Management and Project Systems has several powerful business processes encapsulated including cost planning, budgeting, monitoring progress of AUC, etc…. This article expounds on the features dealing with the management of and settlement of projects to AUCs when the investment measure is to construct a long term asset for the enterprise.

Investment measures are used primarily for planning and monitoring capital investments that are not capitalized directly due to their scope or due to the large portions of in-house production involved. Investment measures are no different from any other internal orders or WBS elements, but they become relevant to asset accounting at the end of the period or the year. The additional functions they have as they relate to the asset under construction are:

- They have an AUC assignment to show the capitalized portions of the total cost.
- During the under construction phase, they have depreciation terms for special depreciation
and investment support calculation.

The AUC assigned to the investment measure is the vehicle for:
- the balance sheet transfer to the corresponding G/L accounts for AUCs
- inclusion in the asset history sheet
- calculation of special depreciation or investment support

The most important control feature from the perspective of Investment Management is the investment profile. A WBS element becomes an investment measure by assigning an investment profile to it. By default, the WBS element inherits the investment profile assigned to the project profile, but it can be overwritten in the individual WBS elements.

Here is a screen print that shows the assignment of the investment profiles to the project profile that all the WBS elements created for the project inherit.

The following is a screen print of the investment profile.

The investment profile determines the following:
- whether an AUC is created when the WBS element is released
- the asset class to be used to create the AUC - summary or line item settlement for the AUC - asset class for depreciation simulation - budget vs plan distribution to the investment measure
- whether a separate AUC is created per assignment in the source structure, meaning a separate AUC is created for each cost element or cost element group specified in the source structure assignments

Debits on Investment Measures
The actual costs on investment measures (WBS elements or internal orders) consist of
- Postings in Financial Accounting
- Movement of goods in Materials Management
- Internal activity allocations and overhead in Controlling

During the under construction phase, it is not possible to post acquisitions directly to the AUC. Acquisitions are posted to the investment measure through account assignment using primary cost elements. During the periodic settlement, the costs are divided into those requiring capitalization on the AUC and those not requiring capitalization on the AUC. These costs are only temporarily represented in Controlling as primary costs until a period-end closing is carried out. At the end of the period, the following happens:
- Costs requiring capitalization are credited to the corresponding investment measure (WBS element) and transferred to the AUC or the fixed asset as the case may be.
- Cost not requiring capitalization are credited to the corresponding investment measure (WBS element) and transferred to CO receivers, such as a cost center.
The graphic below shows the flow of information to and from the investment measure.

Settlement of Investment Measures
During period-end closing, the values requiring capitalization are transferred to the AUC and those not requiring capitalization are transferred to one or more of the CO receivers from the investment measure. The settlement profile, and especially the source structure, plays an important role in achieving the bifurcation and settlement of costs to the AUC vs CO receivers based on where those costs arise from. The source structure is also required when costs from source assignments need to be distributed to different receivers, for example, by percentage assignments. The following graphic shows the costs on a project using the CJI3 line item report for actual costs.
It can be visualized that costs on the project arise from two different cost elements – primary cost element 892014 and secondary cost element 51043000. A primary and a secondary cost element are used to clearly distinguish costs requiring capitalization using the primary cost element and those not requiring capitalization using the secondary cost element. The settlement profile assigned to the project uses an allocation structure and a source structure and allows settlement to an asset and a cost center based on the cost element used to post the actual costs.

The allocation structure specifies the settlement cost elements to be used for each of the cost elements from the source assignment.
Source cost elements for assignment CAP:

Settlement cost element for assignment CAP:

Source cost elements for assignment EXP:
Settlement cost element for assignment EXP:

The source structure assigned to the settlement profile specifies two source assignments – one for cost elements requiring capitalization and one for those not requiring capitalization.

Source assignment for cost elements requiring capitalization:

Source assignment for cost elements not requiring capitalization:

Now, when using the source structure, the settlement rule on the investment measure allows using the source structure assignment in the distribution rule. The example below shows a settlement rule that requires the actual costs created using a cost element from the source assignment EXP to settle a 100% to a cost center.

When settlement is executed for the first time, a settlement rule is automatically created to settle the costs requiring capitalization to the AUC. After carrying out settlement for the project above, a second rule is added to the settlement distribution rules list by the system to settle the remaining costs to the AUC. This is how the settlement rules are transformed after settlement is executed for the first time for the investment measure.

After settlement, the WBS is credited for all the costs using the appropriate settlement cost element specified in the allocation structure. The costs created using the cost elements used in the EXP assignment are settled to the cost center specified in the settlement rule and everything else is settled to the AUC. This is how the CJI3 report looks after settlement:

This article is intended to provide a high level process flow of how settlement is execute to distribute costs between an AUC and a cost center with the usage of a source structure in the settlement profile. As always, please feel free to contact me or post a comment.

SAP PS: User-exits and Customer Enhancements

2010-01-06T17:30:00.005-06:00

For functional consultants, having a list of customization options handy is priceless. Being aware of the possibilities to easily customize the system to meet their needs can add a lot of value. This article is dedicated to exploring enhancements and user-exits in SAP as they relate to the Project Systems module. There are several integration points for the PS module, which means that it adds value to a PS functional consultant to be aware of some of the pertinent user-exits from other related modules as well. I intend to keep this blog live with updates and new additions as I keep thinking of what else might be of value here. Some of these customization options will be discussed here, but most of them are linked from already existing sources, where they are more or less self-explanatory. If you would like to get more information in a given area, you’re welcome to leave a comment here or send me an email.

Essentially, you will be discussing with your ABAP resource to develop the programming code required to achieve the expected system behavior. However, to find out more about each of the enhancements, including available user-exits and their documentation, go to transaction SMOD, enter the enhancement number in the Enhancement field, select the required radio button (Components for user-exits and Documentation for detailed explanations) and click Display.

Here is the list of enhancements available when creating project objects in the project builder transaction CJ20N.

This is the list of user-exits available when creating a network using transaction CN21.

The following is the list that provides the ability to customize order confirmations including confirmations for production orders, network and PM orders. These user-exits are extremely helpful in validating confirmation details against customer-specific fields.

For customer orders and billing, quotation creation and resource-related billing is often used with the PS module, where itemization of the quotation / billing document becomes a point of interest for minor or major enhancements. Here is a link to the SAP help files that lists the enhancement points available for resource-related order billing and quotation creation using the DIP profile:

http://help.sap.com/saphelp_45B/helpdata/en/35/a7b53f9af50d14e10000009b38f9b9/content.htm

Cross-Application Time Sheet (CATS) is heavily used in many client setups to capture labor hours against project WBS/network activities or PM orders assigned to projects. In all these scenarios, there are different customization possibilities at disposal to validate and manipulate time entry data in CATS, which is subsequently transferred to the project. Here is a list of the enhancements available for the CATS timesheet.

When creating budgets using availability control, this enhancement is useful in determining the mail recipients and providing an activity for the availability control.

These are the enhancements available for project MRP using MD51.

As mentioned at the beginning of this posting, I will be updating this list often based on feedback and as I could dig into more of the customizations I have used over the years and in the future. Please feel free to leave your comments.

Logistical Processing for Project Stock

2009-12-22T17:20:00.005-06:00

SAP provides the ability to manage individual stock segments as either project stock or sales order stock. Each of the stock segments can be managed in either valuated or non-valuated stock. This document is aimed at providing an overview of the general business processes associated with the logistical processing of project materials – valuated or non-valuated. In view of the extensive configuration and master data maintenance requirements, it is not feasible to provide extensive screenshots at this point in time, but we’ll save that for later..

A number of business situations require a material to be managed separately from the collective stock in the form of an individually managed stock segment.

- Materials with long replenishment times can be procured using preliminary requirements planning only if those materials are managed in an individual stock.
- Requirements planning for configurable materials in only possible if those materials are managed in individual stock.
- You want to monitor the flow of costs for material used in your projects within project WBS elements as the material goes through the different stages of the production/assembly process
- From an inventory management or requirement planning point of view, it is required to separate materials for one project against another.

The configuration to manage stock for your project as valuated or non-valuated is derived from the project profile and can be changed in the project. However, once the project is created and saved, the setting can no longer be changed.

The “Automatic reqmnts grouping” indicator enables project requirements to be grouped at the top WBS element level for the whole project.

Additionally, the material master should allow individual requirements in the material master (MRP4 view). If the indicator is set to Collective requirements only, project stock (or sales order) stock cannot be used.

A material component can be assigned to a network activity as either a stock or a non-stock item. The item category (stock / non-stock), together with other configuration settings, determines:

- The procurement type
- In which kinds of stocks the material can be managed
- The account assignment category

The procurement type for a material can also be maintained in the material master. If this is maintained, the assignment of a material component to a network activity as stock/non-stock item is validated to ensure compatibility between the behavior of the item category. The following procurement types are available (material master: MRP2 view):

- in-house (internal) production (E)
- external procurement (F)
- no procurement (_)
- both procurement types (X)

Components with non-stock item category (N)Non-stock materials are always procured using direct procurement (these materials are not maintained in stock, therefore, they need to be supplied by a supplier). A purchase requisition is created for the material component depending on the configuration for reservations / purchase requisitions defined in the network profile assigned to the relevant network activity.

Once the purchase requisition is created, it is then converted into a purchase order by Purchasing. If commitments are active for Project Systems, the corresponding purchase requisition / purchase order commitments can be evaluated in the Information System.

Components with stock item category (L)
When a stock item is assigned to a network activity, a reservation is created in the system for the network activity that reserves the specified quantity of the material for the network activity. The material is then procured using Material Requirement Planning (MRP). An MRP can be executed for each WBS element maintaining stock. When the MRP is executed, an availability check is performed for each reservation. If there is not enough material in stock, a planned order / purchase requisition is created, which can then be converted by the concerned department into a production order for internal manufacturing of the item or into a purchase requisition and then into a purchase order for external procurement. This decision to procure internally or externally is made at each BOM level upon exploding the BOM during the MRP run.

The procedure is the same as for non-stock items when the item is procured externally. If stock components are used, a decision could still be made whether the item is manufactured internally or procured externally, but the decision is made by the MRP controller, who may or may not be directly involved with the execution of the project. Furthermore, externally procured items can be sent directly to the customer by placing a third-party order. This indicator is specified in the PS customization in the procurement configuration (OPS8):

Assembly items are items that are assembled in a network activity and are represented by a network requirement quantity. The reservation is also raised with a negative quantity and the receipt date is automatically assigned as the finish date of the network activity.

When materials procured externally are received, they are first posted to the project stock. A reservation is then made either to the network activity or to the production order requiring that material. Account assignment category Q is used for the purchasing documents and the project WBS maintaining the stock for the material is used for account assignment in the purchasing documents. This procedure is different from that used for non-stock items, where the account assignment category is F and the account assignment is made to the network or network activity.

For stock items, if planned orders from reservations are converted into production orders, the production orders and the items held in stock for them are assigned to the stock-bearing WBS element. The same assignment is maintained for subsequent documents. Production orders for semi-finished goods deliver materials to project stock. The materials are then issued from project stock to the subsequent production orders.

Hopefully, this provides a general overview of the logistical processing aspects of project stock. I shall attempt at an example in a future blog.

Excel Integrated Project Cost Planning for SAP

2009-11-15T18:32:00.026-06:00

Excel integrated cost planning is an extremely convenient and powerful tool for project managers. Especially, when monthly planning dollars need to be entered at the WBS element level, this proves to be the only way the project manager would ever be able to get things done on time, because it is extremely time consuming to go through the screens for each WBS element and drilldown into the period screen to enter values for each period in SAP. Moreover, when these monthly values are to be re-forecast every month for the remaining periods of the year, it becomes all the more tedious to manually key them all into SAP.

This document outlines the configuration and procedure for maintaining monthly project cost planning values into a plan version using integrated Excel planning. The procedure begins with uploading plan values from an Excel spreadsheet where planning has been carried out offline. Once the values have been uploaded into SAP, they can easily be transferred to a different plan version or evaluated in the project information system.

NOTE: Cost planning by period requires that you plan by fiscal year, period and cost element. If required, a dummy cost element could be created and assigned to the planning profile assigned to the project profile.

Configuration
In transaction SPRO, expand the project system menu item and browse to the item below.

Choose the “Create Planning Layouts” activity.

Copy Existing Planning Layout
Enter a name and description for the user-defined layout. Choose to copy the standard layout 1-701 (WBS elements: Standard cost elements).

Click on “Create”. The contents of the standard layout 1-701 are copied into the new user-defined layout along with the columns and variable definitions.

Remove Unnecessary ColumnsUnnecessary columns must be removed from the layout. Remove columns other than Cost element and Total Plan cost. Select each column and click on delete.

Click Yes to confirm deletion. The layout now looks like this.

Make Characteristics Available as ColumnsSelect menu path Edit -> Gen. data selection -> Gen. data selection to make the WBS element and Period as available characteristics.

Move Period and WBS Element from Select characteristics into the Available characteristics. Check and Confirm the change.

Add Required Columns for Input
Add a new lead column to add the WBS Element.

Move the WBS Element from Available characteristics to the Selected characteristics. Then, Check and Confirm the change.

Select to display both Name and Description for the WBS Element.

Now, add Period to the layout - select the Total plan cost column and select Edit -> Element -> Change/display. Drag the Period column from Available characteristics to the Selected characteristics and change values as below.

Check and Confirm changes.

Select the Total Cost Plan column to change the column descriptions.

Change the texts to something like this.

Notice that the column text is now changed to Period 12. Click just next to the Period 12 column and follow the menu path below to create a column for Period 11.

Choose “Key figure with characteristic”.

Enter Period 011 for the Period characteristic value.

Change the texts on this element to reflect Period 11.

Repeat the steps above to add periods 010 to 001. Note to click the cursor just next to the left-most Period column to insert a new column/element. When all the periods are done, the layout now looks like below.

If all the columns don’t appear on the screen, click on the next page icon.

Create Planner Profiles
Select the configuration path to create planner profiles for cost planning.
Click on New Entries. Enter Profile name and description.

Select the line for the new planner profile and select “General Controlling”. Select “WBS Elements: cost elements/act input for Planning Area.

Then, click on Layouts for Controlling. Select the checkboxes for Overview and Integrated Excel planning to allow for Excel planning upload for the planner profile. Also, enter a file descriptor.

Click on Default Settings and enter a default version, fiscal year, WBS element and cost element and click on the Overview Screen icon.

Click on Enable Macros. The planning layout is opened in Excel with the specified default parameters. Select to save the file descriptors and the excel file.

Also, remember to save the excel file to the local disk since the file will be used to upload planning values later into SAP. Click the back icon and click Save again. The following message appears – “Preset parameters were saved”.

Procedure to Upload Excel Planning
Now that the configuration is in place, it’s time to upload the Excel file into SAP. The Excel file saved on the local disk is write-protected by default. Change this setting to make the Excel file ready for update by going to Tools -> Protection -> Unprotect in the Excel file.

In order to be able to review these costs later, make sure that the planning profile assigned to the project profile allows the planning cost elements used in the spreadsheet.

Complete cost planning offline in the Excel spreadsheet. Save the file as tab delimited text file. When the spreadsheet is ready for upload, go to transaction CJR2.

Select go to Settings -> Planner Profile and select the previous created planner profile.

In CJR2, select Extras -> Excel Planning -> Upload…; Then, locate the file and select the file descriptor assigned in the planner profile.

Click Execute to upload the file. Make sure that the system issues an OK confirmation.

Confirm Values in CJ40
Go to transaction CJ40 and enter the project number and the planning version used to upload project planning values. Choose the correct fiscal year used for the upload. Select the WBS elements for which the planning values were entered.

Select Primary Costs. (There must be a C in the plan value origin column for these WBS elements).

Go to the menu Go to -> Period Screen. The values entered for each of the 12 periods are displayed in the following screen.

Additionally, the planning values thus uploaded into SAP can be evaluated using several standard SAP reports such as s_alr_87013534 and s_alr_87013544 depnding upon need.

I hope this provides an overview of cost planning using Excel integration for SAP Project Systems. Please feel free to leave your comments and suggetions.

Versions in Project Systems

2009-11-10T16:23:00.037-06:00

In SAP, and more particularly in the Project Systems, versions provide a mechanism to maintain project data with different perspectives for planning analysis purposes during the lifecycle of a project or parts of a project. This post provides an overview of project versions, simulation versions and plan/controlling versions most commonly used in the context of Project Systems.

Project Versions
Project versions show the state of a project at a given point in time. They are used for statistical analysis, such as earned value analysis, or to compare how the project has changed from time-to-time. For example, a project version could be created manually for each phase of the project, e.g. design, implementation, testing, etc... and the project values could be compared between these phases. Alternatively, all or some of the project objects (networks, milestones, etc...) could be copied into a project version everytime a system or a user status is changed. This is achieved by creating a version profile.
Once the version profile is created, it must be assigned to the project profile.
Among other reports, project versions can be evaluated in the system using transaction CNS41. In order to use version data in the analysis, the DB profile for the report must be changed to include version data and the version must be included on the selection screen. The following screen shows a sample comparison report between an operative project and a version.

Project versions can be created using different transactions - CN41, CNS41, CN71 and CN72. Regardless of the transaction, the identifying data for a project version is shown below.

Unlike other versions, project versions cannot be changed after they are created.
Simulation Versions

When planning for a project or during the execution of the project, it becomes necessary to establish “what if” scenarios. Simulation versions provide the ability to create alternative scenarios and the ability to copy an operative project into a simulation, make changes and transfer it back into the operative project. The project planning board (CJ2B) can be used to edit simulation versions and the project information system to evaluate them and compare with the operative project. A simulation profile can be created that determines if objects such as PS texts and documents are copied when creating simulation versions.

The simulation profile must be assigned to the project profile. A simulation version can be created by copying an existing project or completely independently. However, there are certain limitations to simulation versions:

- Manual cost/revenue/payment planning for WBS elements cannot be changed directly in the simulation version.
- Production Resources and Tools (PRTs) cannot be assigned to simulation versions in the project planning board.
- Simulation versions cannot be archived.
- Actual and commitment values as well as actual dates are not transferrable to the operative project.
- Settlement rules cannot be maintained in the simulation version.

Transactions CJV1/CJV2/CJV3/CJV4 are used to create/change/display/delete simulation versions. CJV4 shown below is used to transfer data between operative and simulation versions.
Plan/Controlling versions

When a controlling area is created, the system automatically creates a Plan/Actual version ‘000’ (operative version). Actual values are always recorded in this version. Plan costs are also normally maintained in this version. However, when planning project costs, it becomes necessary to maintain different plan values at different phases or for different purposes for the project. This is achieved by planning costs using a controlling version. The values stored in controlling versions are “operational” meaning that they can be changed (unlike project versions).

Cost planning for networks always happens in the operative version. Controlling versions are only used for manual cost planning in WBS elements. It can be used, for example, to keep the operative version always for actual costs, while planning version P1 is used to store planned values from ECP, version P2 is used for unit costing values, etc... Unlike simulation versions however, you cannot copy a planned version to the operative project. You can however, copy one plan version to the other. Transactions such as CJ9BS can be used to copy values between different versions.

Controlling versions can also be used for cost forecasting, results analysis (WIP/RA), project variance calculation or progress analysis depending upon how the version is setup in general and in the controlling area. These versions can also be evaluated in the project information system. The screen below shows the usage in report CNS41 using a plan version (menu path in the report: Settings -> Value Display -> Plan versions…; specify versions to compare).

I hope this provides a good understanding of the different versions commonly used in SAP Project Systems. Please feel free to leave your comments and suggestions...

A quick starter!

2009-11-09T14:20:00.008-06:00

Participation in SAP implementations anywhere in the project lifecycle is a truly rewarding experience in many different ways. For me, it certainly has been. It is intellectually and interpersonally challenging. Especially, the unique combination of skills required to thrive as a functional consultant make the whole process "premium" with plenty of opportunities for value addition to the client.

I am a SAP FI/CO and PS consultant with an emphasis in the SAP Project Systems module and have been in this area since 2003. Having gained a few years of experience with blueprinting, implementation, configuration and support roles for SAP implementations, I have realized that there is a lot of value I could add to the SAP community by having a presence on the web. I would like to use this forum to offer some of my SAP experiences from a functional and configuration point of view and hear your comments.

I would truly appreciate your reading my blog and providing your feedback. I am also very open for networking.