Cloud ERP Solutions

Ever since the introduction of full scale-ERP Systems in the 1990s, companies have faced high costs of implementing proprietary IT Server Infrastructure and Systems. Cloud ERP Solutions help organizations to improve productivity and reap faster ROI, integrating essential business functions like Accounting, Finance, Procurement, Human Resources, Customer Relationship Management etc. with an internet connection allowing greater collaboration among departments. The late 2000s saw the arrival of Cloud Solutions where the ERP system is distributed from the Cloud and accessed by end-users via Web Browsers. Cloud offerings can provide substantial benefits including reduced CAPEX investments, rapid deployment, and lower TCO.


Evaluation Framework

Given the advantages and disadvantage of Cloud ERP Solutions, Companies need to carefully evaluate various options before they zero in on Cloud ERP. It also depends on whether the company is implementing an ERP Solution for the first time or migrating from its current ERP System or extending the system capability to include additional functionality.

Implementation Size and System Complexity are the two major evaluation factors for choosing Cloud ERP Solution.

Implementation Size

Cloud ERP Solutions are typically suited for small to medium companies since the implementation and support costs are relatively low. Large scale Industries might not find Cloud ERPs meeting their Enterprise Requirements.

System Complexity

A large complex SCM Company may find a Cloud ERP system as an unviable solution mainly because of the fact that their complex customized SCM functionalities will be hard to replicate in the cloud. In this case, a business with multiple subsidiaries might keep a centralized, hosted ERP solution to run the enterprise while providing its subsidiaries with a cost efficient cloud-based solution to run their local operations.

Other factors that need to be considered while moving to Cloud ERP are,

  • Delivery model flexibility
  • Ability to use the application on trial
  • Integration with other applications
  • Business process remodeling
  • Security
  • Platform/mobile compatibility
  • Backups and Recovery
  • Upgrades
  • Service level agreements
  • Training and Support
  • Scalability
  • Reference checks with existing customers
  • Vendor viability

Benefits of Cloud ERP Solutions

Cost: The pay-per-use subscription based pricing model is an attractive option for Industries who cannot afford the initial capital expenditure for IT Infrastructure

Scalability: Cloud based providers can scale up their offerings and Cloud partners are responsible for maintaining both the hardware and software which includes upgrades, patches and refreshes.

Flexibility: SaaS based application like Salesforce offer Bolt-on applications for Advanced Analytics, Collaboration, Finance Management Etc.

Rapid Deployment: Cloud based ERP solutions take very minimal time to implement compared to traditional On-premise ERP Systems

Rapid Updates & Upgrades: Cloud based ERP Systems usually get quicker updates than On-premise Systems

Multiple Languages and Currency Support: Cloud ERP Systems let companies expand internationally, something which legacy systems were not built into.

Limitation of Cloud ERP Solutions

Limited Product Suites, Functionality and Availability: So far Cloud ERP systems are engrossed in providing core ERP functionality and they are yet to catch up with the Advanced Custom Functionalities offered by On-premise Solutions.

Security and Data Risks: The risk of sharing Business Critical Data such as company’s financial information and other related data on the cloud poses potential security threats to organizations. Though Cloud Providers like Microsoft, Oracle, SAP have invested heavily on state-of-the-art security, the perceived data risk still looms large in the minds of the decision makers.

Security and Data Risks: The risk of sharing Business Critical Data such as company’s financial information and other related data on the cloud poses potential security threats to organizations. Though Cloud Providers like Microsoft, Oracle, SAP have invested heavily on state-of-the-art security, the perceived data risk still looms large in the minds of the decision makers.

Organization Resistance: Moving ERP to the Cloud will create significant organization disruptions

Oracle Process Manufacturing (OPM) – Best Practices

This article Summarizes the Best Practices in a Process Manufacturing Industry, which can be achieved by implementing Oracle Process Manufacturing (OPM) Solution. OPM is part of Oracle E-Business Suite of Applications

Business Challenges in a Process Industry


The following two critical Challenges faced by a Process manufacturing organization and the ways to address them using OPM are dealt with.

  • Regulatory requirements
  • Operational excellence

How to address Regulatory requirements

Regulatory requirements in a Process manufacturing industry can be achieved by implementing the following best practices.

Track your Materials efficiently so that they can be recalled at any point in time during the manufacturing process. This can be achieved by leveraging OPM features shown in the figure below. These features not only enable your organization to track your Materials but also address your Regulatory and Compliance requirements.


Material Traceability


Create precise control over the Inventory and Manufacturing Process

Achieve precise control over your Inventory and Manufacturing process by

  • Tracking the movement of the materials between your Inventory warehouse and your shop floor
  • Scale production batches up or down to meet the changing demand.
  • Update production raw material issue and inventory receipts in real time and track Inventory items precisely

Implement Detailed Classification of Item & location


Enable Lot Control on an Item for easy traceability


Enhance Real Time Data collection

Enhance your data collection on the formulations and recipes by adopting real time data collection thru RF hand held devices which can push data into your OPM system while you are

  • On the Shop floor
  • In the Warehouse
  • In the Loading Dock

Leverage Oracle Built-in Device capability and Operators Workbench

OPM Built-in Mobile Interface


Manage Product consistency

Any Process manufacturer has to ensure that the product that is developed is consistent over its entire life cycle to meet Customer satisfaction. Any deviation in this will not only lead to customer complaints bus also compliance violations. Strict compliance requirements of products can be addressed by enhancing the quality monitoring procedures of your Product development. The following features (shown in the table below) of OPM solution can help you control the quality of Products manufactured by your organization and also meet your compliance requirements.


Leverage OPM’s Integrated Quality Management

Integrate quality checks in production process using Automated sampling and approval workflow


How to Achieve Operational excellence

Achieve Operational excellence by maximizing Production efficiency

Use following OPM Process Execution and OPM Production Scheduler features (show in table below) to increase your Operations efficiency



Optimize Cost & improve margin by using following OPM Cost management features


  • Capture precise product costs and monitor actual product costs
  • Optimize product cost structure by minimizing ingredient costs
  • Use Multiple cost methods and improve inventory valuation
  • Conduct detailed cost analyses for current and historical purchased material costs, applied resource costs and batch costs

Compliances for Process Manufacturing Industry


4 Strategies That Would Pave-Way for Your Customers to New Microsoft Dynamics AX Adaptation


In a not so long distant future, it is expected from Microsoft to come out with the already available Dynamics AX Azure to be made available on private cloud and On-premise version. Give the recent developments in Microsoft approach and focus on cloud technology, shows us the long term strategy, which will be adapted for Dynamics AX as a product.

Thus from a service provider point of view it becomes even more important to advocate Dynamics users to consider upgrading from the current version being used. Here we are going to discussing some possible approach which can be adopted moving customers to the newest version of Dynamics AX. Four strategies or upgrade scenarios and beneficial tactics will be discussed, which would help in a seamless migration from the existing AX to New versions of AX.

1. For AX 2012 R3 Users, Choice between Cloud and On-Premise:

It is no secret that when it comes to business logic and Data Models of Dynamics AX 2012 R3 version and new Dynamics AX are similar. So making the upgrade from the AX 2012 R3 to new version would be fairly straight-forward. Thus a more standard approach is all that is needed. But the question which would linger around with both the client and the service provider is to either host the AX on the public cloud, private cloud or to choose On-premise.

The hosting in the initial stages of public cloud deployments of new Dynamics AX will be handled by Microsoft’s Dynamics Lifecycle Services (LCS) Deployment Services. For a better approach suggestion, it would be important for service providers to familiarise with the new Dynamics AX on Microsoft Azure, this can be achieved by gathering knowledge on LCS tools in order to estimate licensing cost and evaluate potential upgraded project risks, such as recognizing solution areas with the highest number of merge conflicts, etc.

When it comes to integration with any third party application the new version of Dynamics AX should be easier to implement when compared to AX 2012 and earlier versions. But at this point-of-time you can only perform code upgrades as data upgrade won’t be available until Fall 2016 at the earliest. In addition, new Dynamics AX does not have any data upgrade scripts yet. And data migration scripts have to be created during the upgrade.

2. For AX 2009 Users, Upgrade to AX 2012 then new AX Version Transition Approach:

A larger number of enterprise takes time to migrate to new versions of Dynamics AX for a number of reasons such as time, resource, budget and on most occasions their familiarity to the existing system. Thus on many occasions enterprise skips versions. Even Microsoft has mentioned that for AX 2009 extended support will be provided till 2018, hinting Microsoft’s intent of wanting the AX 2009 users to upgrade at their own pace.

Transition of customers or users thus becomes an integral part of any upgradation activity. For a seamless transition it is better advised to transition the customers Dynamics AX solution to AX 2013 R3 CU8 on the first place. This might be the most secure and cost effective strategy while planning to move to new Dynamics AX from a version such as AX 2009. As mentioned earlier the new Dynamics AX is similar to AX 2012 R3 CU8 in terms of business logic and data model. So the exposure to the AX 2012 environment will help both the enterprise and individual users from the organization to adapt the AX environment, so making the transition straightforward when new Dynamics AX is adapted.

There are few reasons which has to be taken into account as a service provider to consider upgrade suggestion of AX 2012 R3 to be carried out in 2016 and later upgrade them to the new AX version at a later point of time.

    • Dispersal of Upgrade Costs & Risks Over Time – It has to be noted that jumping few versions to new Dynamics AX substantially increase upgrade costs and risks associated with upgrade project exponentially. So it becomes a more conducive approach to have smaller, well-planned, iterative upgrade steps.
    • Subsiding Upgrade Project Risk- one of the main reasons why an upgrade project is stalled or delayed is because of underestimating the project. There are many factors such as accumulation of unexpected cost and increased error rate. Not taking such factors into consideration would result in the migration project over shooting the project cost and leaves an unsatisfied customer.
    • Avoid the Big Leap- When an organization is running AX 2009 and migrating directly to latest version of Dynamics AX would refer to a big leap when it comes to user’s interface and processes of the system. This sudden change will create unnecessary strain, unease and confusion for users.

3. Full Upgrade or Re-implementation or A Mix Approach:

There are scenarios where as a service provider you might come across unsupported upgrade paths. During these situations we are left with a number of choices such as re-implementation or a combination of upgrade & re-implementation, these approach tends to be more efficient solution provided to the clients than a full solution upgrade.

Few notable situations when the suggestion of re-implementation has to be suggested are,

      • Level of customization which has been implemented in the current system. In case of customizations having conflicts with the new version of standard AX, would make the upgrade complex and costly.
      • Consistency of customer’s data in the existing Dynamics AX solution also determines the strategy to be followed.
      • The use of ISV or any third party integration tool which is not supported by the new version plays a role too.

Similarly, the situation when a mixed upgrade strategy for the customer needs to be suggested.

      • When the requirement for upgrade from the customer is to re-implement only specific Dynamics AX modules.
      • In situations when the customization is actually part of the new version of AX and those customizations needs to be removed, thus only migrates data.
      • If the need is full data migration and code re-implementation. This scenario mainly arises when there are multiple Dynamics AX version used for different businesses and wants to transition/merge them to one corporate solution.

In short to fix the implementation strategy a deep analysis of each specific case should be performed to determine which option is best for your customer. Cost efficient and time efficient options depends on data and customization in the current customers AX version that needs to be upgraded. To plan your upgrade strategy, service provider and the customer should deliberate a variety of factors such as,

      • Source System Version
      • Database Size and Quality
      • Customization and New Functionality
      • ISV Solutions and Integrations with Third Party Application
      • Budget, Timeline, Downtime Limitation and Resources

Thus an initial assessment to identify the discussed factors and in-turn helps in identifying which strategy to be followed for customer’s unique situations.

4. Small Customer, how about Going for NAV Instead

The situation completely changes when the customer or users of older versions of AX such as the AX 4.0 or older, seem to be struck and do not see an efficient means of migrating their existing solution to a new version. The less the 50 users the new version is not available since the limitation is a minimum of 50 users, making the new Dynamics AX too big.

In such situation rather than struggling with the approach or strategy, the simplest of solution are to migrate the existing AX system to Dynamics NAV. Migration to NAV from the existing AX is also made easy with number tools available which make migration easy.

KARYA Technologies’ Microsoft Dynamics AX Service Offerings

KARYA Technologies’ Microsoft Dynamics AX Services are aimed at helping our clients exploit all relevant base functionalities, scale-to growing business needs, integrate AX effectively with internal and external systems such as CRM, Legacy Systems, Mobile Applications and EDI Frameworks and enhance the BI/Reporting capabilities.

KARYA Technologies is a Microsoft Dynamics Certified Partner with a large resource base of experienced and Certified AX Professionals on board.

      • We have a proven record of excellence in Implementation / Upgrades and Production Support.
      • We help AX integrate seamlessly with other Enterprise Systems (like CRM), Web Portals, Trading Partners (like EDI), Microsoft Office Suite.
      • We practice and preach sure-step methodology.
      • We have experience with Localization and Globalization aspects of AX.
      • We can recommend and implement suitable Industry Vertical Add-on Solutions.
      • We have a strong Infrastructure team to support AX implementations.
      • We provide 24x7x365 Operational Maintenance and Production Support for your AX Environment.
      • We have an efficient Global Delivery Model.

To learn more about KARYA Technologies’ Microsoft Dynamics AX.

How To Use SIPOC For Hyperion Planning?


In process improvement, a SIPOC (sometimes COPIS) is a tool that summarizes the inputs and outputs of one or more processes in table form. The acronym SIPOC stands for Suppliers, Inputs, Process, Outputs, and Customers which form the columns of the table.

When we want to start some process management or improvement activity, it’s crucial to get a clear overview of the top level stages of the process. SIPOC helps provide a natural but structured way to discuss a process and get consensus on what it involves before drawing process maps.

SIPOC is often presented at the outset of process improvement efforts such as Kaizen events or during the “define” phase of the DMAIC process.

It has three typical uses depending on the audience:

  • To give people who are unfamiliar with a process a high-level overview
  • To reacquaint people whose familiarity with a process has faded or become out-of-date due to process changes
  • To help people in defining a new process

SIPOC is best accomplished in Team Work and Brainstorming Sessions. To conduct a successful SIPOC session, first provide participants a brief overview of the SIPOC Process, Purpose, Tools/Templates, and especially the keys to an effective SIPOC.

SIPOC Diagrams are very easy to complete. Here are the steps to follow:

  • Create an area that will allow the team to post additions to the SIPOC diagram. This could be a transparency (to be projected by an overhead) made of the provided template, flip charts with headings (S-I-P-O-C) written on each, or headings written on post-it notes posted to a wall.
  • Begin with the process. Map it in four to five high level steps.
  • Identify the outputs of this process.
  • Identify the customers that will receive the outputs of this process.
  • Identify the inputs required for the process to function properly.
  • Identify the suppliers of the inputs that are required by the process.

Here is a simple example of SIPOC for an Automobile Repair process:

In line with the above example, Oracle Hyperion Planning Application (a web-based Planning and Budgeting Solution that integrates Financial and Operational Planning Processes) is explained through SIPOC

Benefits of Using SIPOC Analysis

  • SIPOC is an effective visual tool for defining a process by identifying key activities, outputs and inputs of the process, which gives an overall view of the business scope and enables all team members to view the process in the same light.
  • It provides an understanding of the various process steps and process owners that make up the system for the stakeholders, project sponsors and team members, giving clarity on the scope of the process at an early stage in the project.
  • It associates together the suppliers and customers with the main process, to study and investigate as a whole body, thus analyzing and developing the system from a comprehensive view.
  • It quickly and easily captures the current state of the organization and processes in question, and defines the improvement efforts.

About the Author: Remesh Padmanabhan is a Senior Functional Consultant, Oracle Hyperion Platform, at KARYA Technologies. He is an Accounting Professional with more than 25 years of experience in serving various industry verticals such as Manufacturing, Automobile and IT. His specializations include Quality Control Measures like Six Sigma, ISO 9001 Standards and Business Continuity Management. Remesh is an avid reader and he likes to watch classic movies.

5 Myths About DevOps Busted


DevOps as a service complements the Agile Software Methodology by promoting the communication and collaboration between Development, Quality Assurance and Operations, thereby enhancing the IT Organization’s Capabilities in accommodating rapid changes to Production and Remediating Production Issues as they occur.

But, most of the time, the Core Principle about DevOps is not understood properly. Some of general Misconception/Myth that are associated with DevOps are:

1. Operations + Development = DevOps:

Combining team members from Operation and Development can establish a DevOps operation. This is just a myth. The fact is DevOps is a combination of Processes and Practices that are adopted for the entire delivery pipeline and covers various stakeholders, where two key practices are adopted such as Continues Integration (CI) and Continues Delivery (CD).

2. Complete Automation is DevOps:

DevOps is all about Completely Automating the Build and Release Process. Automation in DevOps forms an integral part of the process, but implementation of Automation is not the only activity associated with DevOps. In DevOps, Process Automation is achieved by using tools such as Puppet, Chef, Ansible, Etc., which are available in the market. It has to be noted that Implementation of Automation should be limited to an extent where it remains under control. Implementation of Complex Automation Scripts in Complex Server can simply end up as a road block, rather than being a solution.

3. DevOps is a Tool:

Implementation of Configuration Management Tools is DevOps. Actually, DevOps has nothing to do with tools implementation. It is just part of the process and as said earlier it helps in Process Automation. Experts often feel that tools in reality undermine the DevOps potential. Automation and Tools form only part of DevOps and the core remains with combining and increasing end-to-end practices of collaboration with CI or CD.

4. No More Traditional IT Roles with DevOps

Each and every role needs to be handled by all the members of a DevOps Team Eliminating any Individual Roles. The real objective of DevOps is to Eliminate the collaboration barrier and not to ask everyone to work by adopting to roles. To make the Support Operation Effective, Specialized Skills and Traditional Roles are valuable for DevOps.

5. DevOps needs a Dedicated Team:

DevOps requires a dedicated DevOps team. This is not true and DevOps gives more importance to the processes rather than focusing on a dedicated team or dedicated role. There are some occasions when the mission of the DevOps team in not defined properly and having a dedicated team leads to more problems. There are even occasions when a temporary DevOps team makes more sense to help streamlining processes.

The fact remains that DevOps as a concept is still evolving and it is bound to get buried under myths. All efforts should be directed towards bursting these misconceptions and align organizational goals with the DevOps principles to maximise ROI.

KARYA’s DevOps Offerings:

Our versatile team of DevOps professionals include top-notch Architects, Automation & Integration Specialists, Application Architects, Open Source Technologists, Cloud Orchestrators, System & Database Administrators, Quality Assurance Professionals, Build / Release / Deployment Managers can help you improve Code Quality, Integrate Continuously, and Deliver Faster. To find out more about KARYA’s approach to achieve Continuous Software Delivery CLICK HERE.

(About the Author:- Praveen Kumar Rajendran works as a Senior Consultant- Presales at KARYA Technologies. He holds Masters’ Degree in International Business from La Trobe University and has wide experience in Business Consulting on various technologies. He loves to write on latest trends in IT and his areas of interest include Mobility, Cloud and Enterprise Solutions.)

How To Maintain Homeostasis Using Business Intelligence Alerts

How to maintain Homeostasis using Business Intelligence Alerts

What is Homeostasis?

Encyclopaedia Britannica defines Homeostasis as any self-regulating process by which Biological Systems tend to maintain stability while adjusting to conditions that are optimal for survival.

If Homeostasis is successful, life continues; if unsuccessful, disaster or death ensues. The stability attained is actually a dynamic equilibrium, in which continuous change occurs yet relatively uniform conditions prevail. An often cited example for Homeostasis is temperature regulation in humans and warm-blooded animals in general.

Key Components

The two important components of Homeostasis are Sensors and Effectors. Sensors monitor and detect changes in the controlled entity and provide the negative feedback for Effectors to carryout corrective measures and these corrective measures remain in motion until the deviation is reversed.

The effectiveness of Homeostasis is in its ability to trigger the corrective measure in real time while the controlled entity is alive, well and able to survive the deviation and also self-correct. It is borne out of survival instincts, the need to survive and perpetuate.

An organization is a controlled entity and in order to effectively monitor and regulate the various processes within it, it is worth investing in the Sensor and Effector Mechanism because they ensure its survival. Homeostasis is nothing new in the business world. Most manufacturing processes are monitored using Industrial and Engineering Control Systems that are self-regulating.

In IT Services the advent of DevOps is a direction towards a seamless response system for dynamic demand on Software, Services and Infrastructure. Machine Learning, Algorithmic Processing of events and transactions and Internet of Things are good examples of embedded Homeostasis in action. In the end, a living optimal entity is a result of an ever present Homeostasis.

Alerts and Sensors

Organizations can leverage their existing Business Intelligence Infrastructure to install Alerts. There is lot more emphasis on the need for On-demand Decentralized Reporting than demand for Auto-course Correcting Mechanisms that BI Alerts can facilitate. BI Alerts are the Sensors. Alerts trigger when certain pre-determined set points are deviated and provide the negative feedback necessary for the Effectors to kick in. These set points are commonly called KPIs but I would like to bring in measures for vitality instead of KPIs. I think Vitality and Homeostasis go together.

Many organizations use Alerts and Notifications from their BI Systems, but not as Cohesive Mechanism for an Enterprise-wide Alarm System to stabilize operations and survive. Balanced Scorecards measure and monitor performance but do not help in keeping Homeostasis in the earliest available opportunity. In order to get to the deep green colour highlight on a Balanced Scorecard, Alerts are a must for course correction.

What must you sustain on a daily, weekly or a monthly basis to remain vital. If the answer is based on Average Foot Fall or Customer Complaints or Sales or Margins. A very simple example of Vitals calculated from these are;


Vitality of Sales = Inclination of Trend line of (Weighted Average YTD Actual Sales (Daily)) minus (Weighted Average YTD Actual/Budgeted Sales (Yesterday/Daily))
{Trigger Alert when Vitality of Sales < 0 degrees} {Stop Alert when Vitality of Sales >= 0 degrees}

Customer Complaints

Vitality of Customer Satisfaction = A Trend line of (Average YTWE NPS (this week) – Average YTWB NPS (week before))
{Trigger Alert when Vitality of Customer Satisfaction < 0 degrees} {Stop Alert when Vitality of Customer Satisfaction >= 0 degrees}

The Trends and Averages may be daily, weekly, monthly or some other period depending on how volatile your parameters are. The average chosen should iron out daily fluctuations and clearly show a trend upward, downward or steady state. Instead of a plain vanilla Average Calculation, a sophisticated Forecasting or other Statistical Models relevant to your industry may be used to calculate the trend and define the Alert set points.

Predictive Analytics to forecast a set point or a trend and thereupon issue an alert can be an effective red flag. Alerts may be graded to denote the significance of the deviation. Since we are talking about Homeostasis, we may also borrow the concept of Early Warning Score (EWS) used by the Medical Community to assess the degree of illness of a patient. In BI Terminology we know it as tolerance threshold in a Balanced Scorecard. Preventive Action kicks in when the Alert goes out in response to meeting an EWS.

‘The Alert System’

The Effectors are the organizational managers and their teams, who have the resources to diagnose the reasons for deviation from Vitals, take corrective measures. On-demand Reporting can be a great tool for Diagnosis. The alerts must be designed to facilitate Drill-through Action to deeper levels of data.

In fact, “Project Homeostasis”, cannot be a success without a robust Data Processing and Integration Infrastructure in place for Analytics. The beauty and the effectiveness of ‘The Alert System’ is in its ability to keep blaring its horns until the fire has been doused. There are no accessible buttons to push to silence the alarms. They can only be silenced by correcting the course of the Trend Line.

Knowledge about your Business, Industry in general and a Creative Imagination are the limits to how Alerts may be defined and implemented in your organization.

KARYA can help organizations design Enterprise-wise Alerts by leveraging your existing Business Intelligence Systems. To know more about KARYA’s Data Management Solutions please log on to

(About the Author- Nagarajan Mahadevan works as Principal Consultant- Data Management Solutions at KARYA Technologies. He is a Techno-Commercial expert and has more than 2 decades of experience in Business Intelligence, Data Warehousing Technologies, Financial Accounting and Management Consulting. His areas of interests, apart from staying abreast on latest IT Trends and Technologies, are Yoga and Indian Classical Music.)