Patent Application
20130218643
This invention pertains to a method for determining whether a company is in compliance with a business program.
The concept of the business program is nothing new. Many businesses have “championed” various programs, such as safety programs or reducing carbon emissions, to show how concerned they are with various aspects of life. The idea of the business program is so well known that it is frequently mocked. For example, the introduction to FOX's long-running animated hit, The Simpsons, includes a segment where Homer Simpson is handling a rod of what is presumed to be plutonium, while in the background Lenny Leonard is standing on a ladder, updating a sign that reflects how many days have passed since the last accident has occurred at the nuclear power plant. As the bell rings to announce the end of the shift, Lenny loses his balance and falls down, showing that the counter needs to be reset back to zero.
But while it is easy for a company to state that they are interested in implementing a business program, making the business program work the way it is intended to work is not so trivial a matter. For example, a company can invest many thousands of dollars in new, safer equipment. But if the safety features of the new equipment are bypassed, the company has made little progress in increasing workplace safety. Similarly, if the new equipment has operational limits (e.g., an upper bound on the operating temperature of the equipment) which are ignored, the new equipment is not necessarily any safer than the old equipment. In fact, workplace safety might have been decreased by purchasing the new equipment, as the hazards associated with ignoring the operating instructions might be worse than those of the old equipment.
The present invention addresses these and other problems associated with the prior art.
Embodiments of the invention include identifying requirements that need to be implemented for a business program. The requirements of the business program can be evidenced in various types of assets. Maturity levels can be determined for asset types with respect to the requirements, in both structural and cultural dimensions. The maturity levels can be evaluated, to determine if the company is in compliance with the business program.
The foregoing and other features, objects, and advantages of the invention will become more readily apparent from the following detailed description, which proceeds with reference to the accompanying drawings.
Before getting into the specifics of how embodiments of the invention can be used to determine whether a company is in compliance with a business program (sometimes just called a “program”), it is helpful to understand some basic concepts. First, a business program is the business logic needed to achieve a sustainable outcome. A business program is separate to business processes implemented by a company. A business program can be evidenced in asset types (and assets), and an individual asset type (and asset) can provide evidence of multiple business programs.
Second, to implement a business program, a company must determine the requirements of the business program, and then identify what asset types will need to be acquired/changed to achieve the requirements of the business program. From an individual company's perspective, “implementing a business program” means identifying the tasks the company will need to take to implement the business program; but before a company can carry out any tasks to implement a business program, the requirements of the business program need to be determined.
An individual business program—for example, a safety program—can apply to any number of different companies. The requirements of the business program are the same regardless of the company implementing the business program: it is only the specific elements of implementation that vary between companies. (The term “implement” means “to attempt to put into place”: as discussed below, there is generally no expectation that success will be immediately achieved and the business program will be immediately functioning.) The business program requirements are specific to a particular business program, in that each business program will have different requirements needed to implement the business program. There can be any number of requirements to implement a business program. For example, it is reasonable for there to be hundreds of different requirements needed to implement a particular business program.
Normally, it is sufficient if a company implements enough of the requirements for a business program to be considered to comply with the business program. But a person of ordinary skill in the art will recognize that it is possible that a company can satisfy additional requirements for the business program beyond the core set of requirements to implement the business program. A company might desire to be “proactive” or “ahead of the curve” in implementing a particular business program. For example, a company might desire to be looking for ways to improve its safety record beyond those required by a safety business program.
Third, implementing the requirements of the business program depends on various types of assets. For example, to satisfy the requirements of a business program, a company might have to acquire new equipment, draft new policies and procedures, and train personnel. Each of these elements—equipment, policies and procedures, and personnel—is a type of asset. Implementing a requirement of a business program often involves multiple asset types: that is, it is not unusual for a single requirement to involve multiple assets of different types. Similarly, it would not be unusual for a single asset type to provide evidence regarding multiple requirements of the business program. Thus, there is a many-to-many relationship between requirements and asset types. The various asset types, grouped into categories, are shown in
Table 1 represents one way to divide assets into categories and types. But a person skilled in the art will recognize that there are other ways in which to divide assets into categories and types, and that embodiments of the invention are applicable to other asset categories and types.
Fourth, it would be nice if it would be possible to implement a business program at a moment's notice—for example, to make all the needed changes needed overnight, so that when the employees arrive the next morning the program is fully implemented. But in practice implementing a business program takes time. Thus, implementing a business program occurs in stages, termed “phases” below. In general, there are four phases in implementing any requirements of a business program. These phases are shown below in Table 2:
Table 2 represents one way to divide a business program into phases. But a person skilled in the art will recognize that there are other ways in which to divide a business program into phases, and that embodiments of the invention are applicable to other phases.
Although Table 2 shows four phases, a person of ordinary skill in the art will recognize that these phases can be subdivided, or described using different terminology, without changing the overall implementation of requirements. Embodiments of the invention cover other organizations of the phases. In a similar manner, the use of the labels “Foundational”, “Standard”, “Advanced”, and “Optimal” are merely labels. Embodiments of the claimed invention are intended to include phases of a business program, regardless of the specific label given to a phase.
The Foundational phase of requirements implementation covers establishing the underlying elements needed to begin a business program. For example, the Foundational phase can include acquiring new equipment needed for a safety program, or implementing a reporting system for workplace safety issues that need to be addressed.
The Standard phase of requirements implementation covers the more basic elements needed beyond the Foundational phase. For example, once a reporting system is put in place for safety problems, resolutions for reported safety problems will need to be determined. Determining how to resolve reported problems occurs during the Standard phase.
The Advanced phase of requirements implementation covers the more advanced issues relating to the requirements. For example, once the immediate problem of resolving a safety problem has been handled, a team can analyze what caused the safety problem in the first place, so that the same safety problem will not recur.
The Optimal phase of requirements implementation covers advances in the how the business program is implemented. For example, a team can look for trends in reported safety problems, and attempt to predict safety problems that have not yet occurred, in an effort to preemptively address these safety problems. The Optimal phase can cove things that go beyond the normal implementation of the business program.
Requirements are associated with a specific phase of the business program. That is, given an individual requirement for a business program, that requirement is associated with only one phase of the business program.
Fifth, most business programs only look at the structural elements needed to implement the business program. For example, most companies implementing safety programs look only at the physical aspects needed to make the business program succeed: new equipment that is safer to use, systems for reporting safety concerns, and so on. But there are cultural aspects as well, that are usually ignored. For example, if employees bypass the safety features—whether because they are instructed to do so by their managers or because they think the newer equipment is harder to use than the older equipment—the new equipment is meaningless. In one embodiment of the invention, there are five different dimensions that need to be considered to determine whether a company is actually complying with a business program, or which the physical equipment constitutes only one dimension. These dimensions are shown in Table 3:
Table 3 represents one way to identify dimensions of a business program. But a person skilled in the art will recognize that there are other ways in which to identify dimensions of a business program, and that embodiments of the invention are applicable to other dimensional organizations.
For a company to be in compliance with a business program, a company should be in compliance within each of the various dimensions: satisfying structure without the various cultural dimensions (Structural Response, Response to Peers, Response to the External, and Response to Leadership) does not truly implement a business program.
Sixth, as discussed above, a business program is the same without regard to the company implementing the business program, or even the industry in which the company practices. For example, a workplace safety program for a nuclear power plant is the same as a workplace safety program for a woodworking shop. The business program itself, its requirements, and the types of assets used to implement the business program, are consistent across companies. Only the specific assets used by the company to implement the requirements will vary with the company. Obviously, then, it is important to know what assets are responsible for implementing various requirements of a business program. With companies potentially having thousands of employees, tens of thousands of pieces of equipment, and hundreds of thousands (if not millions) of documents, examining every asset to find specific assets responsible for implementing a requirement of a business program would be overly burdensome. But while assets are specific to the company, asset types are consistent across multiple companies and industries. Thus, even though descriptions of embodiments of the invention might be made with reference to a particular industry, a person of ordinary skill in the art will recognize that the program is independent of the industry, and the descriptions can apply to any company in any industry implementing that particular program.
Turning now to embodiments of the claimed invention,
Computer system 205 includes set of requirements 230, phases 235, asset types 240, maturity determiner 245, and assessor 250. Set of requirements 230, phases 235, and asset types 240 are discussed above. Maturity determiner 245 determines, for a particular requirement, asset type, and dimension (structural or cultural), a maturity level. Maturity determiner 245 does not operate at a high level, but rather looks at specific aspects of the implementation of the business program, to see how mature those individual aspects are. Maturity determiner is discussed further with reference to
Assessor 250 can assess the overall compliance of the business program. Assessor 250 can take the individual determinations of maturity determiner 245 and combine them to determine whether the company as a whole is in compliance with the business program, or a simpler formulation can be used: for example, that compliance requires the implementation of the business program to have achieved a sufficient degree of maturity in the Competent phase of implementation. Because assessor 250 operates by taking a plurality of individual determinations and combines them to produce an analysis of the overall combination, it is also possible for assessor 250 to assess subsets of the overall business program. For example assessor 250 can assess the maturity of a requirement, a phase, an asset type, or a dimension (structural or cultural) among other possibilities. Assessor 250 is discussed further below with reference to
As discussed above, the requirements (which can be associated with a specific phase of implementation of the business program) can implicate various asset types. For example, a requirement in a safety program might require the modification of particular pieces of machinery (physical assets) to make them safer, new policies (document assets) describing plans to prepare for various emergency situations, and employee training (social assets) in handling emergency situations. Similarly, for a given asset type such as equipment, there can be multiple pieces of equipment that are affected by the implementation of the business program requirement.
While
As discussed above, there are various different dimensions in the implementation of a business program.
Table 4 represents one way to define maturity levels. But a person skilled in the art will recognize that there are other ways in which to define maturity levels, and that embodiments of the invention are applicable to other maturity level organizations.
While maturity levels can be determined for individual requirements, asset types/assets, and phases, it is also possible to assess the maturity of the business program at other levels. For example, a maturity level can be determined for each requirement, each asset type/asset, phase, and/or for each dimension (structural and cultural). For example, for each structural and cultural dimension, the various maturity levels represent the extent to which the company has satisfied the requirements for that dimension. The meaning for the different maturity levels for the different dimensions is shown in Table 5:
Table 5 represents one way to assign meaning to maturity levels for each dimension. But a person skilled in the art will recognize that there are other ways in which to assign meaning to maturity levels for each dimension, and that embodiments of the invention are applicable to other meaning assignments.
One way to determine whether the company is in compliance with the business program can involve asking whether the company has at least reached an average of “competent” maturity level for the requirements associated with the Optimal phase (520). Further, since the maturity level of a particular phase is not determined until the previous phase of the business program is considered at least “competent”, by implication the business program will need to have reached an average of “competent” maturity levels for all requirements associated with the Foundational (505), Standard (510), and Advanced (515) phases.
In embodiments of the invention, a company needs to be considered “competent” in all four phases to be considered to have properly implemented the business program. But it is worth bearing in mind that compliance with the requirements of a business program is a voluntary act on the part of a company implementing a business program. Therefore, in other embodiments of the invention, competence can be determined using other definitions. For example, a company might consider requirements associated with the Optimal phase to be unnecessary, and that the company would be satisfied if it is considered competent through the Advanced phase. Thus, using the descriptions of the phases discussed above with reference to Table 2, to determine that the company is in compliance with the business program only requires a determination that the company is considered “competent” for the Foundational phase (505), Standard phase (510), and Advanced phase (515). In the same vein, a company might decide that the cost to implement certain requirements (which might be associated with any phase, and not just the Optimal phase) is greater than the benefit those requirements provide, and therefore the company would be willing to accept not being considered “competent” in those requirements.
To be considered “competent” for a particular phase, the implementation of the requirements for that phase might need to be considered competent. Since requirements can implicate asset types and assets (as discussed above with reference to
User input 620 reflects what persons familiar with the requirement, asset type, and dimension think about how the company is doing. The questions asked of the users, and the meanings of the possible responses, is shown for the Structural dimension in Table 6, the Structural Response dimension in Table 7, the Peer Response dimension in Table 8, the External Response dimension in Table 9, and the Leadership Response dimension in Table 10:
Table 6, Table 7, Table 8, Table 9, and Table 10 represent one way to interpret how mature a business program is with respect to different dimensions and asset types. But a person skilled in the art will recognize that there are other ways to interpret how mature a business program is with respect to different dimensions and asset types, and that embodiments of the invention are applicable to other interpretations.
So, for example, if a user thinks that the company has adequate written documentation about the responsibilities associated with a physical asset type, the user can answer “3” (or “Competent”) to a question about the completeness of the physical structure with respect to a particular business program. If that same user thinks that the physical documentation exists, but are not yet in a standardized format, that user can answer “2” (or “Basic”) to a question about the completeness of the documentation structure with respect to a particular business program.
Although the above description suggests that only one user is asked for their input, the number of users queried for their input can vary, depending on the situation. For example, it might be that only one user is qualified to state the maturity level of the company for one requirement/asset type/dimension, but a whole team might be qualified to state the maturity level of the company for another requirement/asset type/dimension. By having as many people as possible provide input, the more likely it is that the results are accurate: that is, whether the company is actually in compliance with the business program. After all, if only one user provides input, the results will be very heavily skewed by that user's biases.
By obtaining user input for each requirement, asset type, and dimension, a significant amount of data can be obtained about the status of a business program. This data can then be mined to various purposes. For example, graphs can be generated comparing any of the information in the system (requirements, asset types, phases, structural and cultural dimensions, and scores representing the maturity of the asset type for the given requirement, phase, and dimension). These graphs can be of use to the company to see how the company is doing toward compliance with the business program. These graphs can also be limited to a subset of values in any of the information, if useful: for example, the company might be interested in seeing its progress only in the Foundational and Standard phases.
Among the data that can be mined from this information is whether the company is in compliance with the business program. One way to determine whether a company is in compliance with a business program is to determine if the company has achieved a maturity level of “competent” in the Optimal phase. But as discussed above, it is possible to decide whether a company is in compliance with a business program using other criteria. For example, compliance can be determined by considering all of the information for all phases of the business program.
There are several different ways in which scores 625-1 through 625-n can be combined. One possibility is to calculate the average (arithmetic mean) of scores 625-1 through 625-n. If taken over the entire population of scores 625-1 through 625-n (without regard to requirement, asset type, dimension, or phase), then an overall average score can be calculated. Using the earlier example of scoring “1” for “Initial” maturity through “5” for “Innovative” maturity, an average score of “3” would represent competence, which is the target for determining corporate compliance. Thus, if the average score is at least “3”, then result 705 would indicate that the company is in compliance with the business program.
In general, however, it is less meaningful to compute an overall average across phases than to compute averages for each dimension and each phase (but including all requirements and asset types for each dimension/phase). Such a more focused analysis can be more insightful, as it examines each combination of dimension and phase as a whole, which helps to reveal how a company is progressing in each dimension. Thus, for example, the average might be 3.2 in the Structural dimension, but only 1.8 in the Leadership Response dimension, which indicates that the structural assets are in place, but leadership is still lacking.
As an alternative to computing the average of scores 625-1 through 625-n, assessor 250 can select the minimum score among scores 625-1 through 625-n. Such an approach is necessarily stricter in its calculation, since the average will exceed the minimum value (except in the boundary condition where every value is the minimum value). But by using the minimum score, a company can see exactly where the weaknesses lie: a minimum score of “2” indicates that, for some combination of requirement, asset type, and dimension, the company is not yet considered competent.
Where a score is computed not over all scores but rather over individual subsets (e.g., for a given combination of a dimension/phase), these computed scores can then be combined in any desired manner to compute an overall score for the business program.
Although the average (arithmetic mean) and minimum are presented above as examples of how to determine a result, a person of ordinary skill will recognize that any desired mathematical model can be used to determine a result. In addition, combinations of mathematical models can be used. For example, the average score for a combination of dimension/phase can be computed, but then the minimum of those average scores can be used to make the final determination as to whether the company is in compliance with the business program.
At block 820, a maturity level is determined for the selected requirement and the selected asset/asset type in the various dimensions. Block 820 does not require that a maturity level be determined for the selected requirement and the selected asset/asset type in every dimension. For example, if only one dimension is being analyzed at a particular point in time, then the maturity level of the selected requirement and the selected asset/asset type only needs to be determined for that one dimension. At decision point 825, the system determines if there are more requirements (or assets that can provide evidence of the requirement) of the business program to consider. If so, then control returns to block 810 to select another requirement (or to re-select the same requirement) of the business program. Note that decision point 825 does not require returning to block 810 to ensure that the maturity level of every requirement/asset/dimension is required; decision point 825 only considers whether there are more requirements/assets/dimensions whose maturity level need to be determined at this time. Otherwise, control continues with block 830, where the business program as a whole is assessed based on the maturity levels. As discussed above, there are many different ways to determine the maturity of the business program as a whole. In addition, as discussed above, rather than assessing the business program as a whole, a subset of the business program (for example, an individual phase, or a combination of a dimension/phase) can be assessed. Finally, at block 835, it can be concluded whether the company is in compliance with the business program (or, if only a subset of the business program is being analyzed—such as a particular phase or a particular dimension—whether the company is in compliance with the business program with respect to that subset of the business program).
As discussed above with reference to
The following discussion is intended to provide a brief, general description of a suitable machine in which certain aspects of the invention may be implemented. Typically, the machine includes a system bus to which is attached processors, memory, e.g., random access memory (RAM), read-only memory (ROM), or other state preserving medium, storage devices, a video interface, and input/output interface ports. The machine may be controlled, at least in part, by input from conventional input devices, such as keyboards, mice, etc., as well as by directives received from another machine, interaction with a virtual reality (VR) environment, biometric feedback, or other input signal. As used herein, the term “machine” is intended to broadly encompass a single machine, or a system of communicatively coupled machines or devices operating together. Exemplary machines include computing devices such as personal computers, workstations, servers, portable computers, handheld devices, telephones, tablets, etc., as well as transportation devices, such as private or public transportation, e.g., automobiles, trains, cabs, etc.
The machine may include embedded controllers, such as programmable or non-programmable logic devices or arrays, Application Specific Integrated Circuits, embedded computers, smart cards, and the like. The machine may utilize one or more connections to one or more remote machines, such as through a network interface, modem, or other communicative coupling. Machines may be interconnected by way of a physical and/or logical network, such as an intranet, the Internet, local area networks, wide area networks, etc. One skilled in the art will appreciated that network communication may utilize various wired and/or wireless short range or long range carriers and protocols, including radio frequency (RF), satellite, microwave, any of the Institute of Electrical and Electronics Engineers (IEEE) 810.11 standards, Bluetooth, optical, infrared, cable, laser, etc.
The invention may be described by reference to or in conjunction with associated data including functions, procedures, data structures, application programs, etc. which when accessed by a machine results in the machine performing tasks or defining abstract data types or low-level hardware contexts. Associated data may be stored in, for example, the volatile and/or non-volatile memory, e.g., RAM, ROM, etc., or in other non-transitory storage devices and their associated storage media, including hard-drives, floppy-disks, optical storage, tapes, flash memory, memory sticks, digital video disks, biological storage, etc.: such associated data, by virtue of being stored on a storage medium, does not include propagated signals. Associated data may be delivered over transmission environments, including the physical and/or logical network, in the form of packets, serial data, parallel data, propagated signals, etc., and may be used in a compressed or encrypted format. Associated data may be used in a distributed environment, and stored locally and/or remotely for machine access.
Having described and illustrated the principles of the invention with reference to illustrated embodiments, it will be recognized that the illustrated embodiments may be modified in arrangement and detail without departing from such principles. And, though the foregoing discussion has focused on particular embodiments, other configurations are contemplated. In particular, even though expressions such as “in one embodiment” or the like are used herein, these phrases are meant to generally reference embodiment possibilities, and are not intended to limit the invention to particular embodiment configurations. As used herein, these terms may reference the same or different embodiments that are combinable into other embodiments.
Consequently, in view of the wide variety of permutations to the embodiments described herein, this detailed description and accompanying material is intended to be illustrative only, and should not be taken as limiting the scope of the invention. What is claimed as the invention, therefore, is all such modifications as may come within the scope and spirit of the following claims and equivalents thereto.
This application claims the benefit of U.S. Provisional Patent Application Ser. No. 61/601,466, filed Feb. 21, 2012, which is hereby incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| 61601466 | Feb 2012 | US |
