|
|
|
Personal Blogs
|
|
|
|
Transiliense : On managing and executing change. |
|
|
Therbligs :Random thoughts and observations Published Clips Register
04/12/2006 Trend Leader Baseball's Transformation
03/01/2006 Trend Leader Souderton vs. Interboro
01/25/2006 Trend Leader Smart Cars
01/11/2006 Trend Leader It's an Endless Season for Passionate Players
|
|
|
|
Archive
Contact info@chuckmoyer.com about purchasing reprint rights to the articles listed here.
|
|
Cutting Budgets without Butchering Your Business By Chuck Moyer
You wouldn’t trim an expensive and valuable piece of steak with a butcher knife, don’t make the same mistake with your business or department budget when it comes to needed cuts.
Budget cuts invariably begin with targets. It is a specific monetary amount or percentage reduction out of your planned expenditures for the year. Unfortunately, randomness, malice or self-preservation can determine where the cuts fall.
It isn’t so much the ideal or need for budget cuts that are the problem, it is more in how they are determined and executed. Given the target, most efforts at budget cutting go about looking for the people or group to cut that would be the easiest to execute in the short term. In the pressure and negativity around budget cuts managers of budgets sometimes forget to consider long-term effects, effects on the remaining members of the organization or department, by-products or results indirectly caused by the cuts, and even preservation of a base to rebuild on, should the business turn around from contraction to expansion.
The best way to assess and determine a budget cut is first to understand the drivers of cost /expenditure in your business or organization. Budgets are a result of the effort you propose to do from input of internal or external suppliers to internal or external customers. When budgets are cut there must be one or more of the following to occur: (1) Inputs will be reduced, there is less need for your group’s services, the volume of work has reduced and so should your budget – for your variable expenses (2) efficiencies will be implemented / waste will be eliminated– this is truly the intent of budget cuts, but it the most difficult to identify and implement (3) your group will do less – i.e. less detail, less checks, less offerings, etc. Unfortunately this sometimes means less quality, and lastly (4) Less outputs or slower response time.
When you understand the results and effects of planned budget cuts, then you are ready to focus on the specifics and target the most appropriate and least business significant area for savings opportunity. Attack the achievement of the target amount in waves or layers of cost/expenditures, reviewing how close to achievement you are with each wave before advancing to the next wave.
1. Halt initiation of new spending. Any new expense, or commitment not yet made in writing, must be reviewed in the context of the what the organization looks like or is focused on after budget cuts. Does it still make sense? Will it help achieve the savings targets (net of the expense)? Will it lead to an ongoing maintenance or support cost? It may seem obvious, but you don’t want to spend money on a CNC Machine for an outsourced group.
2. Stop any non-committed one-time charges/expenses. This is one step beyond the previous one, where you are looking to stop any expenses or more specifically, put on hold or suspended, until further review. This targets a savings in cash in the short term.
3. Stop any re-accruing charges, not contract obligated. Take a look at those charges that occur every month. Products or services that the organization or department is no longer using, or are not currently needed are opportunities for beneficial cuts. And since they trickle out in a constant flow they tend to add up quickly.
4. Cut all non-essential consultants. This actually should be a regular review activity, but here you are looking at taking any task, currently being done by consultants, and asking yourself if it can be taken up by internal personnel. Just be sure the internal resource has the bandwidth and capability to take on the tasks in question.
5. Renegotiate existing contracts: Re-pricing/ Deferral. This is where we start to get in desperate levels. We need to ask our partners in business to assist in the attainment of the budget numbers. Be reasonable not demanding here, they have a contract, but they do want to see your company remain successful. If approached from a collaborative and creative perspective, you will likely find a win-win scenario.
6. Cut all Consultants: now we need to baseline the foundation of your business, pull in activities to employees, but don’t overburden the good people you have left, be sure that what you give them is necessary and valuable to the organization.
7. Layoff under performing or non-essential workers. I put this after cut consultants only because equity for a company is how it serves society, and one of the most tangible ways it does that is the sustaining of workers and the means for them and the company to contribute to society. But here is where you need to get rid of your bottom percentile of performers. This is the manifestation of that budget cut goal of lean and efficient operations.
8. Sell off expendable assets; tangible assets that the organization or department is no longer using, or are not currently needed are opportunities to gain cash.
9. Cut back to bare-bone services internally. Especially at this point, but also on all the others, be sure you are not cutting capability to unrecoverable or worse; unsustainable levels. Look at the after-effects of these cuts and ask yourself if business were to pick up, do you have the foundation to build that growth on?
Be careful with targeting outsourcing as means of saving. With out-sourcing there is transition and implementation costs that are always an up front cost increase for the organization. And these efforts work best when you have discrete, quantifiable and repeatable process/procedure transactions that can be contained in a single out and in, and that this service has become a commodity within the organization not a core competency.
Budget cuts are not intended to shut down the business, in fact sometimes they are needed to save the business or re-focus in a new direction. How budget cuts are applied and executed, determine their success to the business. When taken as a chance to review and challenge the expenses of the department, you as a manger have the opportunity to validate and demonstrate the contribution the items in your budget make to the business as a whole.
Composite Application Selection By Chuck Moyer In the selection of third party applications, representing an architectural perspective and consideration is congruous. While any software application choice is done primarily by business requirement and expected benefit, it must balance against a true representation of organizational cost, both in initial procurement and implementation as well as ongoing support and maintenance costs.
Cost support, whether opportunity cost or bottom line expenses; do not end with implementation of a new program or application. Any program does not remain static or self sufficient incrementally adds activities to the general support budget floor for areas like Information Technology and Training.
Intangibles also need highlighting to ensure realistic expectations and validation of assumptions, as complexity, integration, data concurrency, aggregate management, cooperative collaboration and others can impact on future opportunities available or determine efficiency ceilings. Though these elements do not translate well into financial figures they merit in any evaluation just as qualitative risks are weighed in a risk analysis.
Once a technical application capability is available within the current IT configurations, movement away from the already implemented solution would need a sufficient justification to over come the inertia and assimilation already provided by the support, familiarity, and operations elements gained by the embedded application or functionality, likely achieved over a period of time. This understanding and optimization to support and maintain the application/functionality will always need rebuilding with the implementation of a new application or software.
Be cautious to not limit information on consideration choices only to vendor demos or materials which usually focus on features and capabilities which are surface level or marketing centric info. All software providers tend to diminish the efforts involved in transitioning the organization (technically and operationally) from current state to the vision sold in vendor presentations and even less on the assimilation into the rest of the systems and organization elements on an ongoing basis. Selection is ultimately a cost-benefit analysis but cost calculation is only accurate if consideration goes beyond departmental use and includes costs for support, maintenance, intangible impacts, and future stream costs for the organization.
Functional requirements for the organization should map to feature listings of each offering to identify and highlight differentiators between the applications and provide a score card against the requirement objectives of the department or group requesting the solution. Features and benefits considerations based on the collective capability offered by the application will highlight total benefit as some capability of an individual program or application may provide a benefit that more than compensates for another feature or capability where the individual application is slightly deficient.
Most enterprise level applications are not self-sufficient and isolated, and will likely require data from other transactional applications and even have requirements to pass updated information back to source applications to retain data integrity and concurrency. The leveraged advantage of ‘packaged’ applications is that the integration and data sharing efficiencies are designed into the application. Any separate application requires data transfers for foundation information like customer data, invoices and the like, that are maintained or created in other applications.
Even if generalized interfaces are available, mapping and system capacity will need to be allocated on an ongoing basis to maintain this data transfer and monitor it for error handling. Most likely efforts for developing and maintaining custom interface programs are another incremental and ongoing cost support new composite application. Additionally when data transfers are required there immediately becomes the issue of data latency, where events and updates in one system is not able to reflect in other systems until some time delay that is required to process the data transfers. These data delays can sometimes affect the efficiency of individuals or groups as they are not operating with the ‘latest’ information.
Application knowledge within functional IT and support areas to accommodate solution design, trouble-shooting, reliability and performance improvement, backup and recovery, help desk support and training will need to be developed in the organization and as you increase the number of different applications each functional area needs to support or in-depth knowledge of each application will be reduced as individual resources will spread their understanding over the collective applications they need to support.
With separate applications, account and access management for users becomes more complex. Automated tools for segregation of duties conflicts will be more difficult to configure and manage, and costs for yearly compliance reviews for S/OX compliance may increase as access considerations for individuals must be analyzed across applications, especially when financial applications are under consideration.
With a separate application upgrade schedules between systems upgrades now become separate thread events with increased frequency and complexity require planning and oversight. This represents an incremental yearly effort activity for not only IT support personal but business users as well.
As you add separate application systems to the enterprise footprint complexity and cost impacts will be felt in the area of disaster recovery, as more separate applications need to be staged and backup, as well as coordination between data sequence and timely in the separate systems should a multiple system recovery be needed.
Conclusions The efforts, resources and cost to implement and develop reports for either solution can be similar. But the complexity introduction and year over year costs for servers, maintenance fees, upgrade activities, skill development, integration support, and disaster recovery is increase in cost from an organizational and IT support standpoint as is, may be contrary to budgetary pressure to reduce these expenses year over year. As IT support for additional applications increases the maintenance cost floor, be sure that composite applications consider that cost increase as well as factors of complexity for future endeavors and those composite applications that bring a large return or better yet a continuing return that more than covers these implicit and explicit IT costs are just good business.
Enterprise Application Evolution Path By Chuck Moyer Are your enterprise applications on an evolution path toward extinction? An application, like any sub-system, has to change over time to maintain viability and contribution. As the skills of users increases and business environment changes, so must your enterprise applications. Users stop using applications that do not progress with the organization, as they no longer fit their changing needs. To match their needs, users begin adding separate applications, usually requiring different platforms and creation of multiple interfaces. This can also lead to inefficiency like data replication and reconciliation. To support the business over time, focus on a primary maturation path for your enterprise applications. This sets an architectural model and focuses skill development and how solutions targeted by IT. There are three evolution paths for enterprise application: Customization, Packaged, and Composite. Custom: Focus on Development
When choosing the custom path you are taking control of keeping the features and capability of the application in line with the business by continuing to modify or alter the program(s) through either in house or out sourced programmers. The infrastructure to support the effectiveness and efficiency of this path focuses on the skill sets of programming, requirements documentation and change management. With focus on development, capabilities around skill development and training for employees need support. Finding new employees knowledgeable about your system’s function and operation is difficult and developing that knowledge internally will be the only source to fend off attrition and retain knowledge depth. The organization itself is the only knowledge pool and highlights retention as a priority in Human Resource management in the IT department. For much of the same reasons, Testing resources within your organization will need to be skilled in structuring tests to match requirement definitions and understand more about the applications, than in other evolution paths, as finding bugs will likely come from exploratory testing. Focusing on development, your organization is the source of innovation. Either through the request and drive of the business to new capabilities or efficiency gains identified through process reviews. Those that are driving the new development must understand not only business need and opportunities, but also the limitations and capabilities of current or emerging technology to be current in the industry and against competitors. Developing standards lays a foundation for sound structures for development build up. Avoiding a patchwork development, where focus is only on the new features; not the optimal placement within the application logic or infrastructure, will keep the ‘stacking ice cubes’ syndrome at bay. The further evolved into the customization path makes it increasingly difficult to continue or adventure on the other evolution paths, due to the amount and intrusiveness of the customizations. Vendor Package: Focus on Collaboration and Upgrades
With vendor packaged application, at times referred as ‘shrink wrapped solution’ you are buying into the totality of what is offered by an off the shelf enterprise application. In this path, initial selection of appropriate software or IT services vendor is critical. You are selecting a vendor based on their ability to evolve the software in line with the needs of the industry and provide support to keep solutions current through regular upgrades. With this focus your company has to leverage the capabilities of the application to the fullest extent. Your return on investment basis is using as many of the beneficial features and capabilities with in the application. Additionally the organization will need structure and efficiency around the regular tasks of executing upgrades and applying patches. Since others in your industry are likely using the same application, your competitive advantage will result from quick implementation of new features introduced in the newest version. Internally system analysts must understand the application capabilities and limitations thoroughly. When accessing internal business needs the direction is not on designing a solution but determining how to apply the tools and capability within the application, currently used or not, in ways that will satisfy the requirement. Requirements not available need prioritizing and communication to the vendor, through user groups, advisory boards or direct contact with vendor’s development group. And any decision to go outside the package application for a solution, either customization or ancillary system, must consider the future effect of upgrades or dependency limitations as your enterprise application footprint expands beyond the primary vendor. This increases the complexity in analysis and consideration for all future activities and resources. This is more a relationship focus and a partnership, best used when programming and innovation are not the core strength of your company. However, this does not have to take on the ‘wait to see what comes next’ passivism. There should be numerous channels of active communication with the vendor during their development cycles to suggest and propose new functionality or changes to leverage more benefit in current application use and ongoing support and maintenance. This benefits the vendor with creative input and innovation from regular users and translates to industry wide implementation of beneficial improvements and even standardization with future versions of the application. But keep in mind that unique, company centric solution will not translate well for vendors trying to sell to general industry markets. Composite: Focus on Integration and Error Handling
Companies good at synergy can make the case for a composite evolution path for their enterprise applications. This is a building process, with best of breed applications, an assembly from the blocks that best fit the needs of the business. Organizations following this route must be effective at discovery and evaluation of new applications or bolt-ons. They must avoid being distracted by the latest buzz or flashy solutions and must envision how the new add becomes assimilated into the current IT structure and the effects of differentiation and increase complexity do to the enterprise application whole. The IT organization must continually be in a mode to transition partial transaction or user process to alternate solutions. Implementing new solutions, as opposed to continual upgrade of existing software, to achieve new capabilities. The skill set within IT is likely broad and shallow, as different applications and vendor software requires understanding to a maintenance level, but full leveraging and creative application is likely unachievable. Training efforts will focus on assimilation and understanding, based on vendor supplied materials or instruction manuals, as training development needs will be minimal. Because of the heavy integration aspects of the composite solutions, universal integration standards, which are robust, provide a framework for easier assimilation of new programs and applications. As data and transactions move through different application capture, review, and correction of errors, either technical or process oriented need appropriate resources and timely resolution to keep the disparate systems working as a whole. With the Patchwork assembly of enterprise applications, universal technical foundation and overhead level control both transactional and technical will provide the efficiency and means of management for the composite based enterprise. Staying on the Path
Each path has strengths and weakness. Selection of the primary focus for your organization depends on the capabilities and goals of your organization as a whole and particularly your IT organization skills and resources. Having every IT application evolution fall cleanly into one and only one path is unlikely, but conversely trying to stand on all paths at the same time will cause increase in complexity and inconclusive improvement over time. Your organization should pick one primary evolution path appropriate to the objectives of the organization and design process capability and education resources to reinforce that path. Taking another path for a specific solution then should be justified along with the understanding of in-house limitations, and subsequently help needed, to make the deviation effective and sustainable with the overall direction. Paths not only provide guidance in direction but also make the movement in that chosen direction easier to travel. The same applies to enterprise applications and systems as IT organizations should target the future progress and viability of the solutions for the business and leverage the investment in technology over the long term for a better return.
Testing to the Node of Normalcy By Chuck Moyer Dec 2005
One of the difficulties in planning effective software testing is determining the balance of too much testing against not enough testing. Testing all transaction possibilities in complex applications is impractical within project timetables. At the other end, not enough testing and you may miss the identification of errors in operation or transaction, which are later, embarrassingly, discovered by users.
The solution is to focus the testing not only on the specific item that got changed, but also some levels of upstream and downstream points on the process/transaction flow. How far up and down the testing should go, is to the node of normalcy.
Testing is to find errors. Testing that identifies no errors, is wasted time. The difficulty comes that you can only determine the true effectiveness of a planned test after it is completed. But some of this post-dilemma can be mitigated by a full understanding of the change being made, where the risk factors and impacts are and where in the program use the alteration no longer effects transactional processing.
A system change typically has a ripple effect, like a stone in a pond, where the risks and effect of the change are greatest at the point of alteration and reduce in risk and effect as the transaction flow moves away from the point of the code change. Data alteration works in the same way, but keep in mind that the use of a defined data element may be several steps removed from where it is entered.
Accessing the impact and risks areas of a change require a holistic view beyond the change itself into how the change affects the system and process flow. The nodes of normalcy are the points, ahead and behind the change, in the transaction flow. Beyond the forward node of normalcy point, transactions operate identical to the way they worked before the change.
At this point the code modification, or data alterations, are completely processed and assimilated into the application’s record and has reached a logical transaction stopping point . Consider the inputs and outputs around the change to understand how far from the impact point of the change to take the analysis. Ensure the integrity and consistency of transactions received and handed off, at the point of the code change. Then trace these dependencies to their end points, where they reach a static state or an existing functionality within the system alters them successfully. This is your forward node of normalcy point.
The introduction node of normalcy point lies ahead of the change in the transaction flow. Before the node of normalcy point the introduction of the change in the system has yet to manifest either in transaction logic or data record. Existing data, before the change, is identical at this last point of normalcy, before the change. Integration level testing must consider the change’s effect on the entire system. The focus of unit testing is successful processing of the changed code.
The balance of these two testing focuses provides a thorough simulation of use and impact. If you can plan to test to the node of normalcy you address the higher risk areas, so that you can find more errors and establish a logical stopping point where continued testing reaches diminishing returns. A focused test plan originates at the point of the change and expands outward to the nodes of normalcy. Testing outside of these boundaries represent low risk areas and does not need to be included in test plans. System and transactional processing at these points reach a normal operation, logically unaffected by the changes made.
Application Security Triangulation By Chuck Moyer Nov 2005
Can you state where you are standing right now in a quantifiable and verifiable manner? Saying you’re here or there is too general, it’s a name, a general reference not a position and doesn’t pinpoint it exactly. Now say the same for a person’s access to your enterprise application. Can you pin point exactly what they have access to, what they can do and is it the right access for this person? A successful audit or verification is consistent and repeatable.
Global Positioning works for where you are located with triangulation. Your distance from three fixed and known points can pinpoint your position, having less than three leaves multiple possibilities of location. Because of the complexity of application security, this same triangulation concept can represent a quantifiable and verifiable position for an application user. This gives an application security ‘position’ for the user. One point of reference for user setup is not enough to position them with the appropriate access. Anything less is just a name, implying generalization, variability and assumption. Any ambiguity can leave an individual with under or over access. Under access and the individual cannot perform their job. Over access and the company is at risk.
Three questions need to be answered to provide the right access: Who they are, or verification of the user. What they do, or identification of their role. How they perform, or determination of access. Larger systems, meet somewhere in the middle, with application access. The extremes can be each individual has separate and unique access versus all users have access to the same thing (usually everything). Both of these extremes are not likely and make managing difficult from either a user maintenance level or from a security level. Verification of the user Who is it that needs access to the system? The fundamental access determination parameter is identification of the unique user. The user is proclaiming their selves to the application and asking for the access for which they are entitled. All the other system setups for security and access controls are means to assigning them to users. They are not the control; they are the means to facilitate the control. Filters and supplemental rules around the type of user (employee or vendor) location, clearance, and duration are all elements of user-based access. The authentication of the individual is auditable based on employee/HR records. This is the ‘who’ portion of the security triangulation. This is the same for initial setup and auditing, the individual user is the unique entity that can or can’t do transactions or tasks in the system. And for any security process or procedure that defines what they should be able to do and only do.
Identification of the role The role that a given user fills in the organization defines what task they will perform. To make it easier to manage, many organizations aggregate and generalize this role. There are patterns and similarities in what people need access to do, the more similarities are grouped the easier it is to manage, implement, audit and automate. This is the ‘what’ portion of the security triangulation.
Menus and Responsibilities provide the connection for the users into the programs of the application and provide the limitations of what they can do Determination of the access Just like there was a grouping of similar roles for easier management, there is a grouping of access and transaction capability. This is the ‘how’ portion of the security triangulation. The programs, forms and reports are the means of altering the system records. Process definitions in the organization define the grouping of these transaction capabilities. The sequence and latitude define the performance and control.
The more complex the determination of these points, the more variability there is in your security results. Variability increases failure possibilities. If you can simplify it to a pure logic statement (i.e. with one and only one result) you can even take additional steps to automate the control. Thus saving resources and making auditing that much easier.
The triangulation builds through the association through these points of reference for user access. First between User and Role, then predefinition and generalizations by the matching of Role to Access makes the second connection. The last triangulation point of Access to User, completes application access determination giving a specific and verifiable access definition to your enterprise system. Application security triangulation defines whom, does what, and how it accomplishes their contribution to the organization. |
|
|