Enterprise Resource Planning an effective way for implementing Corporate Social Responsibility programs
An Enterprise Resource Planning software system has been used for some time now to enhance team collaboration, business processes and the organization as a whole. Nevertheless, there are still innovative and new ways in which it could help to make the entire corporation more productive and efficient. One of the most recent developments is to use the software as a way to better guidelines of CSR or Corporate Social Responsibility.
As ERP adoption grows, so must the desire to ethically and responsibly runs a business, both for the good of people and of the company. By using the already comprehensive data collection, analysis powered by ERP apps to link them with CSR, companies could become more responsible socially in the eyes of the public and their clients.
The idea is for existing apps could be the perfect place for adding extensions to help manage CSR guidelines being drafted and finalized by the ISO or International Organization for Standardization under the fledgling ISO 26000 standards. A couple of years ago, ISO launched the development of International Standard that provides social responsibility guidelines for organizations to follow. The work aims to encourage voluntary commitment to social responsibility and lead to common guidance on definitions, concepts and methods of evaluation.
Since ERP systems already acts as central information depositories for numerous key roles and processes in business, it is the perfect place to add further tracking abilities for social programs. This would include things such as labor relations, human relations, environment and corruption which are all being addressed under an ISO 26000 standard. This makes perfect sense and is a natural extension of the program’s data tracking, reporting, management and oversight capacities. It helps provide a more concise manner of tracking and flow of vital information in case disasters such as an oil rig explosion for instance happens. It could help companies enhance their CSR through making such incidents more transparent. As information is power and if data is automatically tracked, it could support ethical firms even during crisis scenarios. Furthermore, if corporate information and decisions are tracked and documented, there’s less opportunity for corruption, according to the ISO proposals.
By creating corporate social responsibility into the software, it will link new responsibilities to an existing app that already has and manages other major corporate data. When risks are determined and a risk mitigation plan is made, the risk management that directly exists in the system that is widely used throughout the firm allows execution of the mitigation plan to be automated to a much larger degree. A separate risk mitigation tool might leave executives guessing as to whether the plan they created is being followed and this may be ead to various unpleasant surprises.
This is truly smart thinking. The BP disaster in the Gulf of Mexico is just one incident wherein a link between ERP and CSR could be extremely beneficial to society. This is a first huge step and another example of how much people have come to rely on the software, notwithstanding its complexity and challenges. The program may not be easy, but it surely helps businesses and could ultimately help boost corporate responsibility anywhere.
Check out some of the Enterprise Resource Planning configuration and customization processes
One way businesses are coping with the challenge of optimizing and upgrading enterprise apps is to avoid customizing. For their part, service providers are offering more options for configuring applications for particular requirements and industries. However, in some cases, configuration options are becoming numerous and layered that they present their own challenges.
That is why some organizations hold off on upgrades, weighing the benefits of the new features against fixing broken adoptions. The key is not to customize. While it might be appealing to add few code lines, customizations have a way of multiplying and adding up to trouble, especially during upgrade cycles. When integrating an ERP system to a website, the two words that one is likely to hear are configuration and customization.
Both works in conjunction with one another, but there is a subtle difference between them. Configuration deals with the system components but not the business process requirements. Configuring enables the components to work within a given environment, including currencies, language, time zones and more. On the other hand, customization specifically operates to suit the business needs. This could include anything from adjusting screens and views to changing information that’s displayed for a given group.
Configuring an enterprise resource planning system is of the most critical parts of the process. This means changing the parameters that meet the organization’s language, financial, shipping and customer-facing needs. One could also configure the program to recognize revenue through a certain set of specifications, such as product line or geographical unit. Most configurations survive software upgrades while certain ones do not. Configuration is the normal framework set-up, such as fields, parameters and workflows. The changes are a normal part of any implementation and do not need changes to the source code.
Customization is one of the most controversial topics that surround ERP software. It requires changes to the source code and also a higher level of technical sophistication. Often, business objectives and wants could be met via set-up and configuration than customization. The ERP process could be as large a task as the company requires it to be. Although the ERP package should be configured before it is used, customization is optional. However, it greatly boosts the functionality of the program. Tailored solution may include expanding the functionality with third-party freeware, company-centric task management processes and more. Most organizations begin with the full intention of leveraging off-the-shelf package when they upgrade, replace or implement an extensive application. Nevertheless, as companies get into implementation details, request to make one or more customizations to the program are inevitable.
Every organization is unique and no single solution is going to meet 100 percent of company requirements. Nevertheless, finding the right ERP with the best functional fit would ensure that tailored requirements are minimized. Finding the right program involves defining a clear set of needs and choosing the best solution based on the needs. Often, customizing could be avoided via changing company process or using the workflow features of the package. When customization is required, the modifications must be reviewed and approved by some kind of control body, for instance a change control board.
The ten common disasters and disappointments of ten Enterprise Resource Planning system
Before implementing an enterprise resource planning system, an organization should be aware of some issues. Troubled multi-million dollar software deals that create spectacular failures and big spending nightmares, embarrassing and expensive lawsuits over botched implementations and breaches of intellectual property.
Below are ten ERP scandals that could serve as warning for those planning an upgrade or implementations of this system.
1. The $400 million upgrade to the supply chain of Nike and ERP systems created a $100 M loss in sales, a twenty percent stock dip and a collection of class-action lawsuits. This was back in the year 2000 and the terrifying results were because of a bold enterprise resource planning, CRM project and supply chain that aimed to update the programs in to one superstar one.
2. The failed technology implementation failed to help Hershey’s operation during the Halloween season in 1999. Hershey’s ghastly issues with its system supply chain apps prevented it from delivering $100 million Kisses for Halloween and caused a dip in the stock at about eight percent.
3. In the fall of 2004, more than 27,000 students at the University of Massachusetts and Stanford and Indiana University as well were forced to do battle with ERP apps and buggy portals which left them at best unable to find their classes and worst unable to collect their financial aid checks.
4. The epic tale of the centralization of HP of its disparate North American systems onto one SAP frameworks proves that one could never be too pessimistic in terms of an enterprise resource planning venture management. In 2004, HP’s project managers knew all things that could go wrong with their rollout but did not plan for so many of them happening at once. Eventually, the undertaking cost $160 M order backlogs and lost revenue which is more than five times the estimated cost of the venture.
5. The garbage-disposal giant Waste Management is still embroiled in a $100 million legal battle with SAP over an eighteen-month ERP software installation. The garbage –disposal giant filed suit and claimed that SAP executives participated in a fraud sales scheme which resulted to massive failure.
6. All wasn’t well with bedding-maker Select Comfort’s multi-module system implementation, supply chain and other apps. Thus, in 2008, with serious shareholder pressure to tend the $20 million more project that was indicative of very poor management judgment, the company put the undertaking on hold.
7. In January 2006, Oracle boasted that it’s halfway through the Fusion Applications development process. The master plan was to create the next generation of applications that are thoroughly standard. Over three years later, people are still waiting for the first generation of its suite of Fusion Apps.
8. When CIO magazine surveyed 400 information technology leaders regarding their enterprise systems in early 2008, CIOs declared they remained committed to traditional, on-premise systems regardless of aggravating integration and high-cost issues.
9. The details of the popular ‘mooning’ between Hasso Plattner of SAP and Oracle’s Larry Ellison have become an urban legend. IN 1996, Ellison’s sailing crew was reported to ignore Plattner’s wounded sailing yacht that has a broken mast and bloodied crew member. Oracle and SAP have not stopped battling it out both on land and water ever since.
10. Fallout with the massive CityTime payroll system project in New York which was wracked by cost overruns and a criminal investigation to an alleged kickback scheme that involves former employees of systems integrator SAIC and the subcontractor TechnoDyne.
Transparency in custom software development is not an ultimate goal but is a tool for a successful application
The main focus of a custom software development is designing and developing applications that are specific to the client’s requirements. Usually, the focus of the development is to deliver websites that are attractive, effective software solutions and fully optimized. However, when it comes to the transparency in developing customized solutions, it is considered as a tool rather than a goal.
Transparency is a word that has been around for some time, especially in the context of digital projects and partnerships. As a matter of fact, it is touted continuously by client and vendors alike as an ambitious or even boastful attribute. By saying that translucency is a tool instead of a goal, it means that it is not an objective in and of itself. Let’s sight an example of a window. It is transparent so that one could see what is going on outside. The window is needed to make decisions regarding the clothes to wear based on the weather outdoors for instance.
Another example is a glass that is transparent in order to see what is going on inside. This is important to make decisions regarding whether or not one wants to drink the liquid. The same thing, in true partnership clarity is a resource. Relationships in the development of tailored apps are strongest when all sides could be consistently confident that everyone is working toward the same objectives and goals.
Not the development team, the project manager knows the goals or budget better than the owner of the product. That is why, no one is better equipped for directing team toward success. In this scenario, transparency could take the form of project dashboards as well as other metrics that provide visibility toward progress. The dashboards are there to help the product owner drive. Transparency as a tool or set of resources isn’t an endgame but a lofty objective, but only when it is service to even loftier goals.
Being translucent is a major contributor to the success of most internet based businesses nowadays. Not having a face-to-face interaction in doing business on the web could often lead to doubt and uncertainty for any prospective client. When considering being more transparent as an organization, one could see red flags and warning signs that tell one to reconsider. The biggest reason for this is that being transparent typically brings along a familiar sidekick, which is vulnerability.
Even though the word could be a double-edged sword, as long as one plays the cards right and runs a good business, it should not be intimidating. Transparency could in fact liberate one and enable the business to thrive and breathes in confidence and trust in the eyes of possible clients. Customer relationships are the most vital part of a software developer’s business and so professionals should continually look for ways to strengthen and foster those relationships and discover new opportunities. For every software development firm or service provider far and wide, it is a good thing to keep in mind that being limpic is a tool to build effective and successful custom apps.
Three critical questions that an organization needs to ask the software development company
When it comes to selecting the right software development company, unless an organization knows exactly what it is doing, or has recommendations through word of mouth, it could be hard to know where to begin. Even if there is a referral by mouth, it is still worth having several objective criteria against which to judge the software vendor, so one could decide if it is the right option.
In order to make a good choice, there are some critical questions to ask the software development company to have a successful software project. The answers to these questions could go a long way of figuring out which company is best.
Question 1: How does the company ensure that it fully understands the requirements of the software project?
Sixty-eight percent of the project fails, based on the study in the year 2008. One of the big reasons is that the developers often misunderstood the business concern that the client expects the program to solve. Worst, the vendor may give no thought as to how the client expects the package to work from the perspective of the user. A service provider should build a functional prototype that makes it easy for customers to make clear their expectations before wasting both effort and money getting them wrong.
Question 2: How does the vendor limit ‘Work in Process’?
When programmers have to divide their attention and time working on numerous client projects simultaneously, it is analogous to too much undertaking in process. Putting aside one piece of the task and selecting a new one takes up a lot of time and energy. Most of all, it is frustrating when a developer is near to a breakthrough solution.
When developers have to split their time and attention working on multiple client projects simultaneously, it’s analogous to too much WIP. Putting aside one piece of the task and picking up a new one consumes a lot of a developer’s time and energy. It’s especially frustrating when a developer is close to a breakthrough solution. The same as all creative thinkers, programmers work best when they could devote big blocks of unbroken time to a project. Working in developing teams help adjust to the inevitable ebb and handiwork flow that any service business will experience. It further provides an environment in which every individual developer could do the best job.
Question 3: How does the vendor deploy code from development to production?
The biggest source of risk is when code is moved from the development environment, meaning the computer wherein the programmer coded it, to the production environment in which the server where code would run during use. This is called deployment. One wants a service provider who practices automatic deployment against a manual method. The automatic deployment tools enable development firms to work in uniform evolution, testing and production environments, thus potentially damaging discrepancies are eradicated from the beginning. More than that, they allow for continuous delivery of code towards any environment and even a live production one without affecting uptime.
Outsourcing Software Development & Global Trend 