Wednesday, June 23, 2010
The Efficiency Impact of Insufficient Business Software Usage
Today, software is a given in business. Whether information is your business or you simply need information about your business, software gets you the information you need. So why then do so many businesses reduce their operational effectiveness by trying to get by with fewer software licenses than they really need?
Lack of available software for the knowledge workers in your organization has severe, often hidden, business consequences. While managers may think they are helping their business by limiting the number of software licenses to “just those who really need it,” they may instead be reducing operational effectiveness to the detriment of their business. Insufficient access to software adds to the cost of poor quality (COPQ) in a business.
Consider these consequences of insufficient software:
Improper Training and Acculturation. In many organizations, the employee on-boarding process does not include early access to needed software. As a result, initial training programs miss the mark or teach less efficient behaviors than those possible when the correct software applications are available. Poorly trained employees can deliver poor customer service, engage in a higher number of clerical errors, and negatively affect employee morale.
Initial Period of Inefficiency. When licenses are not available for new employees, even beyond their initial training period, economic loss occurs during the waiting period to get on “the system.” Until then, payroll is spent on less efficient employees and bad work habits are further instilled.
Improper Outsourcing and In-Sourcing. When a particular knowledge worker who could do a job, does not do a job because they do not have access to the software, they are forced to refer the task to someone else. This can result in costly external outsourcing. When another firm is needed to do a job that could be done if the right software were available to that person, extra costs and delays occur. Frequently, referring a task out to another worker means referring to another employee. These referrals create delay, introduce greater opportunity for miscommunication, and are inherently inefficient because of unnecessary communications surrounding, the request and the review process.
Duplicate Work. Some companies maintain two separate software applications to perform essentially the same task, because they do not have sufficient software licenses for all workers to use one system. Some workers are on the old system while others are on the new system. Quite often, in these organizations, there is an employee who spends hours every week re-entering data or running batch jobs to synchronize systems – all of which could be avoided by working on one system only.
Bottlenecks. When only a few of those who need access actually have access to certain business software, bottlenecks occur. Important business activities are delayed needlessly because the process is dependent on a limited number of persons who have access to the appropriate application. Some workers may be sharing a license, which means only one worker has access to the software at any given time. The waiting time for the available license creates need for communication, adds delays and creates bottlenecks.
Overstaffing. When a particular software application is incorrectly labeled as a specialty and specific knowledge workers are hired to operate the software, the result is overstaffing. Increased specialized staff requirements can often be avoided by simply increasing the availability of software and training more workers on the use of the software. Sometimes these overstaffing inefficiencies can also be necessitated due to overly restrictive user rights management within an application. The user may have a license but does not have the user rights needed to perform the task. The economic impact is the same.
Reduced Employee Morale. In today’s world of social media, rich applications, real-time integration and software mashups, lack of software access can be extremely frustrating to employees and result in reduced employee morale and higher turnover.
Lack of Interdepartmental Enrichment. Is there a negative cost when salespeople are unaware of customer service issues because they are “not on the system” that keeps track of customer service problems and solutions? Absolutely. Extending software and information access beyond traditional departmental boundaries can enhance business processes. When the engineering team can directly access the customer support system, they may be able to propose immediate solutions or even detect product defects earlier than if they do not have access and must rely on monthly reports or other means of information sharing.
Inefficient Business Processes. Perhaps the bottom line of failing to use software or using the wrong software is the cost of an inefficient business process. Most organizations go through initial training on a “how-to” use a software application. Entry-level instruction typically covers the performance of basic tasks. Without more advanced training and training on “when-to” and “why-to” use software, processes are executed ad-hoc or without full benefit of the efficiency built into the software system. Software underuse has severe economic consequences across all departmental functions in an organization: administration, finance, engineering, production, marketing, sales, distribution, service and operations.
Competitive Weakness. Organizations that underuse software and skimp on the number of licenses available fall prey to competitors that operate at maximum productivity and software-enhanced efficiency. Organizations running without a sufficient number of software licenses will fall behind in innovation, time-to-market, market share, production capacity, customer satisfaction and top and bottom line financial performance.
Insistence on expensive formal ROI studies and usage reports can incur a long and usually hidden list of business costs that can be easily avoided by simply taking a more aggressive view towards the availability and use of software. Software that works is worth every penny of its licensing cost. Cloud computing does not eliminate the problem, in fact, it exacerbates it. When software is viewed as an operating expense rather than a capital expenditure, artificial pressures increase to limit usage. Smart business people will make certain they have enough software licenses available for all of their users including sufficient licenses for future growth. How many licenses do you need?
Thursday, June 17, 2010
Procurement Software: Building Supplier Relationship Management (SRM) Software with uniPaaS for Requisition and Purchasing Management
When building business applications, Supplier Relationship Management (SRM) is one of the important business functions that is often overlooked by application product managers providing software solutions to specific vertical industries. Either SRM gets crushed under the weight of heavy supply chain focused logistical processes or it gets oversimplified by vertically focused ERP systems that simply track vendors and suppliers in the address book and keep track of purchase orders and accounts payable. As a result, rich, usable procurement system features are frequently not available to those involved in the requisition and purchasing process. But it should be clear that vertical industries are not only unique in the ways that they manufacture and sell, they are also unique in the ways that they consume. And more importantly, great efficiencies and cost savings can be built into your software by paying careful attention to the proper design of supplier and purchasing related business processes.
ERP systems tend to squeeze a few purchasing related features into what they will call the “source-to-pay process.” To meet the needs of purchasing managers and others involved in the process, an add-on package for SRM is made available that interacts with the back-end ERP. But what functionality should you include in a uniPaaS application designed to meet customer needs for SRM? I believe a good software product manager needs to ask the right questions in order to create a good solution. Here are a few ideas:
Understand the Business Need. Is the organization a manufacturer driven by a supply chain mentality? In this type of organization, the purchasing process is viewed as an input into the supply chain, work-in-process is viewed as a natural part of the manufacturing or shop floor operations, and finished goods delivery is viewed as the output of the supply chain process. Demand forecasting, optimal inventory levels and logistical considerations such as just-in-time delivery will be paramount to achieving organizational efficiency. Other organizations tend to be more adhoc in their purchasing processes with less predictable relationships between demand forecasts and the specific types of requisitions that will follow. Large service organizations for example, will tend to have more variation in purchases with less predictable inputs and outputs. But this does not mean that purchasing officers do not need automation. Concerns here tend to be in identifying which supplier relationships are most in need of improvement. Should bulk purchase agreements be considered? Should contracts be setup or is the purchase pattern not likely to repeat. How can the software you create begin to categorize and recognize purchasing patterns in order to identify potential efficiencies?
Security, Role Based Access Control, and Management. Who are the users of the system? What are their user rights and responsibilities? How is information archived and preserved? Who can view the information? Who can initiate a process, modify it, approve it, and confirm that it took place and that goods were received and used for the intended purpose? How will those responsible for spending/requesting, budgeting and managing/approving be able to see reports, KPI’s, dashboard views and access their tasks or “To Dos” in the purchasing/requisition processes? Have needed alarms, alerts and escalations been built into the process? Will users be able to access the system over the Web and on handheld devices?
Requisitioning. Create a clear requisition process. Too many companies jump straight to a purchase order process. A PO is submitted and approved without a separate internal requisition request process. In larger organizations, the functions are clearly separated. Approval processes and workflow need to be automated. Does the system handle proxy approvals when the primary approver is not available? Are there acceptable substitutes for the materials requisitioned? What constitutes “comparable goods”? Is there a legitimate need for sole source items? What alternate processes are needed for capital expenditures or unbudgeted items?
Order Management. Once a requisition is approved, orders need to be generated. Can similar requisitions be combined into one order? What quantities should be ordered for maximum economic efficiency? Should a replenishment point be established? What is the ideal inventory turn? Will EDI processes be used? Are some POs communicated verbally, by email, FAX, postal mail? What about the increasing number of orders placed via websites? Is there a method in place for tracking the numerous legal agreements being executed via the web? How are sources of supply identified and matched to requisitions? Are Google-like searches and fuzzy searches available to help source the correct supplier? Are multiple vendor quotes (bids) required? Are the effectiveness of negotiations tracked? How are the actual orders generated and tracked? What are the requirements for recurring orders? How many layers of approval are required? Are procedures needed for internal sourcing and inter-company transactions?
Receiving and Settlement. Are suppliers meeting their delivery deadlines and promises? Are concessions offered being delivered? What triggers the payment process and settlement. How are invoices received matched to orders placed? How are returns and claims handled? Can unused materials be returned? What is the business rule for such returns? Do processes need to be identified for matching purchases to specific projects, departmental budgets, or customer accounts? Are expenses being passed on to customers directly or marked up? Are costs being properly tracked and reflected in COGS? What requirements are there for multi-currency? Are interfaces needed for international tariffs and customs? How will you account for drop shipments? Are proper invoicing triggers in place for drop shipments? How are shipping methods compared and costs evaluated and tracked?
Satisfaction Management. Were the internal customers satisfied with the products or services delivered? Did the materials pass inspection and testing? If not, what remediation steps are required and how are these tracked? Is there a grading system for suppliers? Are order histories easily accessible? Can vendors be easily compared? Are their market prices involved that can be used for comparison?
Contractual Management. Often contractual relationships need to be assessed at a higher level than that of individual orders? Are quantity commitments and discounts being met? Is there an orderly methodology for tracking terms and conditions? When should an agreement be on your paper versus the vendors’ paper?
Master Data Management and Disambiguation. Resale organizations have huge problems around master product data management. Efficiencies can be achieved and sales can be increased simply by having the right information. Product numbers, names and descriptions frequently change for identical or nearly identical items. Failure to recognize same or similar items can result in lost sales, overstocking and other problems. Multiple units of measure may also be applied to the same goods. How are these differences best reconciled?
Conclusion.
Every industry is unique and the software product manager designing applications for a specific industry can create use case interviews and surveys to help identify the purchasing and requisition patterns that need to be built into the supplier relationship management you build with the uniPaaS application platform.
ERP systems tend to squeeze a few purchasing related features into what they will call the “source-to-pay process.” To meet the needs of purchasing managers and others involved in the process, an add-on package for SRM is made available that interacts with the back-end ERP. But what functionality should you include in a uniPaaS application designed to meet customer needs for SRM? I believe a good software product manager needs to ask the right questions in order to create a good solution. Here are a few ideas:
Understand the Business Need. Is the organization a manufacturer driven by a supply chain mentality? In this type of organization, the purchasing process is viewed as an input into the supply chain, work-in-process is viewed as a natural part of the manufacturing or shop floor operations, and finished goods delivery is viewed as the output of the supply chain process. Demand forecasting, optimal inventory levels and logistical considerations such as just-in-time delivery will be paramount to achieving organizational efficiency. Other organizations tend to be more adhoc in their purchasing processes with less predictable relationships between demand forecasts and the specific types of requisitions that will follow. Large service organizations for example, will tend to have more variation in purchases with less predictable inputs and outputs. But this does not mean that purchasing officers do not need automation. Concerns here tend to be in identifying which supplier relationships are most in need of improvement. Should bulk purchase agreements be considered? Should contracts be setup or is the purchase pattern not likely to repeat. How can the software you create begin to categorize and recognize purchasing patterns in order to identify potential efficiencies?
Security, Role Based Access Control, and Management. Who are the users of the system? What are their user rights and responsibilities? How is information archived and preserved? Who can view the information? Who can initiate a process, modify it, approve it, and confirm that it took place and that goods were received and used for the intended purpose? How will those responsible for spending/requesting, budgeting and managing/approving be able to see reports, KPI’s, dashboard views and access their tasks or “To Dos” in the purchasing/requisition processes? Have needed alarms, alerts and escalations been built into the process? Will users be able to access the system over the Web and on handheld devices?
Requisitioning. Create a clear requisition process. Too many companies jump straight to a purchase order process. A PO is submitted and approved without a separate internal requisition request process. In larger organizations, the functions are clearly separated. Approval processes and workflow need to be automated. Does the system handle proxy approvals when the primary approver is not available? Are there acceptable substitutes for the materials requisitioned? What constitutes “comparable goods”? Is there a legitimate need for sole source items? What alternate processes are needed for capital expenditures or unbudgeted items?
Order Management. Once a requisition is approved, orders need to be generated. Can similar requisitions be combined into one order? What quantities should be ordered for maximum economic efficiency? Should a replenishment point be established? What is the ideal inventory turn? Will EDI processes be used? Are some POs communicated verbally, by email, FAX, postal mail? What about the increasing number of orders placed via websites? Is there a method in place for tracking the numerous legal agreements being executed via the web? How are sources of supply identified and matched to requisitions? Are Google-like searches and fuzzy searches available to help source the correct supplier? Are multiple vendor quotes (bids) required? Are the effectiveness of negotiations tracked? How are the actual orders generated and tracked? What are the requirements for recurring orders? How many layers of approval are required? Are procedures needed for internal sourcing and inter-company transactions?
Receiving and Settlement. Are suppliers meeting their delivery deadlines and promises? Are concessions offered being delivered? What triggers the payment process and settlement. How are invoices received matched to orders placed? How are returns and claims handled? Can unused materials be returned? What is the business rule for such returns? Do processes need to be identified for matching purchases to specific projects, departmental budgets, or customer accounts? Are expenses being passed on to customers directly or marked up? Are costs being properly tracked and reflected in COGS? What requirements are there for multi-currency? Are interfaces needed for international tariffs and customs? How will you account for drop shipments? Are proper invoicing triggers in place for drop shipments? How are shipping methods compared and costs evaluated and tracked?
Satisfaction Management. Were the internal customers satisfied with the products or services delivered? Did the materials pass inspection and testing? If not, what remediation steps are required and how are these tracked? Is there a grading system for suppliers? Are order histories easily accessible? Can vendors be easily compared? Are their market prices involved that can be used for comparison?
Contractual Management. Often contractual relationships need to be assessed at a higher level than that of individual orders? Are quantity commitments and discounts being met? Is there an orderly methodology for tracking terms and conditions? When should an agreement be on your paper versus the vendors’ paper?
Master Data Management and Disambiguation. Resale organizations have huge problems around master product data management. Efficiencies can be achieved and sales can be increased simply by having the right information. Product numbers, names and descriptions frequently change for identical or nearly identical items. Failure to recognize same or similar items can result in lost sales, overstocking and other problems. Multiple units of measure may also be applied to the same goods. How are these differences best reconciled?
Conclusion.
Every industry is unique and the software product manager designing applications for a specific industry can create use case interviews and surveys to help identify the purchasing and requisition patterns that need to be built into the supplier relationship management you build with the uniPaaS application platform.
Friday, June 11, 2010
When Software Security Really Matters: Developers turn to uniPaaS
Application security is one of the real strengths of the uniPaaS application platform. We don’t often say much about it, because I think most uniPaaS developers simply take the security of the uniPaaS application platform as a given. One recent announcement serves as a clear reminder however, that the uniPaaS application platform is truly a star among application platforms when software security is a top concern. Magic Software recently announced a contract with the Military Police unit of the Israeli Defense Forces. The agreement includes the uniPaaS code-free application platform and iBOLT business integration suite. This decision was made by the IDF as part of an effort by Israeli defense authorities to strengthen information security.
"Once implemented, both systems will provide the military police with real-time status reporting and a full picture of nation-wide operations at any given snapshot, for hundreds of system users," Yoram Aharon, Magic Software Israel chief executive officer, said in a statement that received attention by UPI, FoxBusiness and scores of other news outlets.
With the global network security market predicted to reach about $9.5 billion by 2015, securing a new Web based application against internet hacking is harder than before. The proliferation of new viruses, malware and hacking attacks continues to rise.
Making sure your Web browser and business software is full patched, your Antivirus and Firewall software running and up to date with the latest definition sets doesn’t come cheap or simple.
The power of the internet without the vulnerability of the browser
The uniPaaS application platform is non-browser based. Instead uniPaaS applications sit within their very own dedicated sandbox. So it’s not subject to the security threats that browser-based applications typically suffer from.
In addition, the message and protocol used to communicate between the Server and Client in uniPaaS applications is proprietary and secured. With the Client not directly accessing any back-end databases, enterprises can prevent font-end users from directly accessing sensitive data files, and avoid potential data theft or corruption.
Internet applications serve as a target for malicious threats. These threats are categorized into three main categories: Network threats, Host threats, and Application threats. Magic Software offers a comprehensive White Paper on the security of Rich Internet Applications. For additional information on RIA Security, I recommend this White Paper. It does a good job of identifying threats, countermeasures and whether it is a uniPaaS issue or an IT infrastructure security issue external to uniPaaS.
A number of recommendations should be kept in mind when securing a uniPaaS RIA application:
Friday, June 4, 2010
Workshops Galore
Today marked the first full-day online uniPaaS workshop conducted by Magic Software Enterprises Americas for Magic Software University. The idea behind online workshops is to provide uniPaaS (and iBOLT) developers with in-depth training around intermediate and advanced topics from anywhere and in only one-day. Technically these are not online or computer-based courses (self-paced uniPaaS courses have been offered for some time) but rather distance-learning experiences.
The next uniPaaS workshop will be held June 18, 2010 and is titled:
Insider's Guide to Advanced RIA Development with uniPaaS
Developers using uniPaaS, know that it handles the detail work for them when linking to, say, different kinds of databases. Developers can create a data source that can be used in a program, but the actual physical data source... ISAM, SQL, XML ... can be determined at runtime or based on which components are used. The uniPaaS RIA Rich Client extends this functionality so that users can run a program over the Web on various hardware platforms, using the same sort of uniPaaS programming developers are familiar with. In the RIA workshop developers will learn how to develop, optimize and deploy a rich internet application.
uniPaaS developers who enroll in this workshop will learn how-to create interactive Rich Internet Applications (RIA). The course will cover the supporting architecture for RIA. One of the most fundamental concepts discussed, and a key difference with client-server uniPaaS applications, is the Rich Client task life cycle. The course dives deep into the construction of rich client tasks and the task life cycle as this is a key concept. Also discussed are the runtime behaviors that you can expect with uniPaaS RIA and the details of the deployment environment. The course will also teach developers how to simulate multiple document interface (MDI) environments. Although uniPaaS RIA is a “browser-free” application environment, you can still include a browser control inside your RIA application so the workshop teaches you how- to incorporate Web interaction inside the RIA experience. Students will also learn how-to build RIA applications for Windows Mobile devices. Since RIA applications involve both server-side and client-side application logic, the workshop also covers performance awareness and optimization of RIA applications. Finally, the course shows you how-to monitor your RIA application once deployed.
Students taking this workshops should already have taken a “Getting Started with uniPaaS” or “Migration to uniPaaS” course. In addition, you need to be familiar with such concepts as Web browsers, Web Servers, Web Sites, HTML, URLs and addresses. The course requires a current version of uniPaaS. These details will be discussed when you register for the course.
The course cost is $699 and payment and registration details can be arranged through either Brian Pitoniak or Megan Kirby of our sales operations team at (949) 250-1718.
The next uniPaaS workshop will be held June 18, 2010 and is titled:
Insider's Guide to Advanced RIA Development with uniPaaS
Developers using uniPaaS, know that it handles the detail work for them when linking to, say, different kinds of databases. Developers can create a data source that can be used in a program, but the actual physical data source... ISAM, SQL, XML ... can be determined at runtime or based on which components are used. The uniPaaS RIA Rich Client extends this functionality so that users can run a program over the Web on various hardware platforms, using the same sort of uniPaaS programming developers are familiar with. In the RIA workshop developers will learn how to develop, optimize and deploy a rich internet application.
uniPaaS developers who enroll in this workshop will learn how-to create interactive Rich Internet Applications (RIA). The course will cover the supporting architecture for RIA. One of the most fundamental concepts discussed, and a key difference with client-server uniPaaS applications, is the Rich Client task life cycle. The course dives deep into the construction of rich client tasks and the task life cycle as this is a key concept. Also discussed are the runtime behaviors that you can expect with uniPaaS RIA and the details of the deployment environment. The course will also teach developers how to simulate multiple document interface (MDI) environments. Although uniPaaS RIA is a “browser-free” application environment, you can still include a browser control inside your RIA application so the workshop teaches you how- to incorporate Web interaction inside the RIA experience. Students will also learn how-to build RIA applications for Windows Mobile devices. Since RIA applications involve both server-side and client-side application logic, the workshop also covers performance awareness and optimization of RIA applications. Finally, the course shows you how-to monitor your RIA application once deployed.
Students taking this workshops should already have taken a “Getting Started with uniPaaS” or “Migration to uniPaaS” course. In addition, you need to be familiar with such concepts as Web browsers, Web Servers, Web Sites, HTML, URLs and addresses. The course requires a current version of uniPaaS. These details will be discussed when you register for the course.
The course cost is $699 and payment and registration details can be arranged through either Brian Pitoniak or Megan Kirby of our sales operations team at (949) 250-1718.
Subscribe to:
Posts (Atom)