2009年3月11日星期三

financial concepts in oracle ebs r12

think globally,
work globally
manage globally

native business flows

The objective of this guide is to present those concepts to you. This guide discusses how
you might:
• Represent your registered companies and management organization in the system.
• Report and analyze your business data.
• Account for your businesses to management, investors, and authorities.
• Share services across your world wide operations.
• Understand what other products do within the E-Business Suite.
• Control and ensure compliance across your organization.
• Analyze and evaluate your enterprise performance.
• Secure your information.
• Specialize in particular industries.

Chart of accounts (COA) is a list of the accounts including a unique number of each allowing to locate it in each ledger. The list is typically arranged in the order of the customary appearance of accounts in the financial statements. A chart of accounts can track a specific financial information. Each account in the chart has assigned a unique identifier, typically an account number. Each account in the Anglo-Saxon chart is classified into one of the five categories: asset, liability, equity, revenue, and expense. Separation of individual accounts by several numerical places allows multiple new accounts to be placed between existing ones.



33/128

2009年3月4日星期三

From R/3 to ECC & SOA

Out with the Old and In with the New: From R/3 to ECC & SOA (Part 1: CHANGES)


This topic comes in 3 installments. In the first blog, we shall walk through the changes that have occurred over the years concerning SAP’s ERP technology, and what ignited these changes. We’ll also take a look at how SAP’s present and future go-to-market strategy of the ECC platform shares a close connection with SOA, and how the two are interrelated.

Then in the second and third blogs, we’ll dive deeper into the impacts of this overall change from R/3 to ECC, considering why it is necessary for SAP practitioners and customers to increase their awareness and up-skill themselves in terms of the new capabilities that ECC brings. The third blog will also reflect on why we see evident push back and slow assimilation from some SAP users in terms of fully realizing and utilizing the enhanced benefits of ECC (of which SOA is an integral part).

But let's not get ahead of ourselves...first let us see how ECC came to be what it is today.

What has changed from SAP R/3 to ECC?

So we all know that SAP has gone through a lot of changes since the 1990s. Just to summarize briefly... R/2 became R/3 (which is related to the term ‘real-time’ and consists of 3 tiers of architecture or layers: Presentation, Application, Database). With the advent of R/3, R/2 was used mostly for mainframe architectures.

Then in 2004, what was considered to be SAP’s R/3 enterprise (version 4.7) was enhanced with the addition of SAP’s first web application server (WAS 6.20), thus providing integrated web capabilities that were actually built into the ERP platform for the first time ever.

It is important to note here, that although the ITS (Integrated Transaction Server) platform had already come into existence offering web-enabled capabilities, the major disadvantage of ITS was that it was not integrated with what at that time was a completely ABAP-based core application server of R/3. There were other complexities involved as well, due to having 2 non-integrated application servers (which I won’t go into as part of this blog).

WAS, on the other hand, provided a completely integrated application server core of ERP. Also, the inclusion of both ABAP and JAVA stacks (complementing each other in countless ways) greatly enhanced the capabilities of WAS, as compared to R/3’s application server. One of the many examples of WAS’ web-enabled functionality is its ability to expose BAPIs as web services. This particular feature supports the notion that WAS is claimed to have lead the way for the ERP structure to have its underpinnings grounded on SOA, mainly because of its capacity to expose core SAP functions as web services.

So here we are in 2009, and it has now been 2 years since SAP officially released their latest version of ERP, which we know as SAP ECC or ‘ERP Central Components’.

As we bring the focus primarily on R/3 and ECC, it’s important to realize that within a timeframe of 10-15 years, SAP have gradually and increasingly brought a more versatile and multi-faceted environment for enabling flexible business solutions.

The diagram below depicts the overall shift from R/3’s highly stable but rigid functionality to a far more sophisticated platform, which has been designed to be a lot more adaptive and agile.

Changes from R/3 to ECC

Moving from left to right, the architecture gets more loosely coupled from the core, while the SAP NetWeaver-based application platform provides the architectural foundation and progressively assimilates more technologies. Also, by 2007 you see SOA becoming the focal point of ECC’s architectural strategy, supported by the fact that literally thousands of enterprise services (the heart of SOA) cover all the major functionalities inside ECC.

So here’s a recap: SAP R/2 --> R/3 --> SAP R/3 Enterprise --> mySAP ERP 2004 --> SAP ECC/ERP 6.0

Now that we’ve covered a brief history of SAP’s evolution over recent years, it is important to identify and address the REASONS that brought about these changes and why this evolution of the platform was necessary to support business demands of today.

Why this change was necessary...

Today’s business demands for ERP are far different and more complex than the demands of yesterday, simply because there is big distinction between the current-day business models compared to the business models of the 1970s. The main factor with business models of today is the high level and frequency of change that organizations experience (due to acquisitions, mergers, shorter product lifecycles, and globalization). SAP has responded to the changing demands for ERP by addressing what is more relevant in the present for SAP customers and practitioners, which can be summarized as follows:

  • The need for flexibility and cost-effectiveness to configure/customize
  • The need for easier integration with non-SAP platforms
  • The need for better reporting and process visibility for decision-makers
  • The need for better support for industry-specific business needs

Essentially, R/3 is not feasible in current business requirements anymore, primarily due to the following 3 reasons:

  1. No longer boundary walls of just internal processes

    In previous years of doing business, customers generally focused on their internal processes. They didn’t have much linkage and direct system interaction with external forces such as their vendors, suppliers, partners, nor was the idea of having extended business networks very common or necessary before. But gone are the days when companies could function independently from their suppliers, partners, and vendors. Nowadays, these companies are required to integrate their systems with the ‘enablers’ mentioned in order for their businesses to thrive.

  2. No longer a need for extensive training

    Another reason that this change needed to happen: since the R/3 system was so rigid and rich in its functionality, it was built to be utilized primarily by highly trained users. So there was a good deal of training involved in enabling users to be able to maintain the system. Also these days, constant user training is not very feasible or practical in any given organization’s continuously changing environment.

  3. No longer can generic solutions be applied – because business cases vary

    Because the R/3 system had more generic functionality, it could not necessarily apply to every business, and everyone knows –- no two business models or business' processes are exactly alike, since there are always variations. So there ended up being a lot of customization required to work around R/3’s general functionality, thus making future upgrades more difficult and expensive.

Here’s a brief summary of what has changed:

The extent to which ERP has evolved from R/3 to ECC can best be summarized by the following points in relationship to the images below:

Differences

[Above image adapted from Dr. Hichem Maya’s presentation called “SAP NetWeaver® Overview” from the SAP World Tour ’06]

In a nutshell, the main differentiator is the SAP NetWeaver platform. With NetWeaver as the foundation, ECC is capable of assimilating the use of both JAVA and ABAP languages and easily supports new product introductions. Since NetWeaver Developer Studio is for JAVA-based development and ABAP workbench is for ABAP-based components of the new ERP system (but with improved and additional features), it is clear that these development tools significantly enhance ECC’s functionality, further supporting and validating the main distinctions from the R/3 system listed above.

Additionally, the user interfaces have a noticeable contrast when weighing R/3 against ECC. What sets them apart is that in ECC, one can easily develop/customize the user interface according to user preferences (with the use of in-built tools like Visual Composer and WebDynpro). Similarly, the layout of ECC’s UI is way more process-centric as opposed to transaction-centric, thereby further facilitating usability for business users and streamlining workflow.

So now that the key differences have been identified, I shall bring the first part of this topic to a close.

Next, I will pick things back up in Part 2 by addressing the impact of these changes that have happened from R/3 to ECC on a solution approach level and a system level, as well as the need to up-skill in order to keep up with these changes.

In the meantime, one more thing for you to mull over is...

What impact does ECC and SOA have on SAP consultants, managers, shareholders, customers, etc...?

Ranjan Baghel , an Associate SAP practice Director in Fujitsu, educates and advises SAP customers and practitioners about utilizing SAP's latest go-to strategies around ECC6 and its SOA underpinnings.

Out with the Old and In with the New: From R/3 to ECC & SOA (Part 2: IMPACTS)

Picking back up where we left off from Part 1, this part transitions from the differences between R/3 and ECC on to the impact this change has had on the way ECC-based solutions are implemented.

So when we consider the major impacts of the recent changes from R/3 to ECC on SAP users and customers, the biggest one in my mind is using (or being encouraged to use) a different implementation approach in terms of methodology.

A Fundamental Difference: ASAP vs. Architecture-Centric Methodologies

The approach for implementing any system prior to ECC has always been based on ASAP methodology. It is what most SAP practitioners have followed when delivering R/3 based solutions and has been the methodology of choice by many among us. So understandably, such wide acceptance and familiarity of ASAP makes folks reluctant and slow to switch to an altogether new approach. But now that ECC is in the forefront, SAP calls for a new approach and has declared it as the Methodology for Accelerated Transformation to SOA (a.k.a. SOA methodology).

And there’s no denying that this is quite different from our standard ASAP methodology in that instead of using an approach in which implementation is almost primarily focused on configuration based solutions (ASAP) -- ECC's SOA methodology starts with a detailed evaluation of the customer’s unique business processes. So we see a major departure from using any baselines or pre-configured criteria, as is the case with ASAP methodology.

Business process-based approach

One important catalyst for the genesis of the SOA methodology was the limitations resulting from having a methodology centered primarily around SAP provided baselines, as well as an almost completely ‘one-size-fits-all’ solution approach. This usually meant that organizations’ business processes were not given enough emphasis nor were the underlying process-based problems completely addressed.

Alternatively, when looking at the SOA methodology as the appropriate counterpart to ECC, you will see that it is largely driven by a subjective view of the unique business and architectural requirements for every implementation. As mentioned in Part 1, ECC’s key differentiator from R/3 is that it moves away from a very rich and generic functionality that prevailed in the R/3 era, and moves towards a more business-focused approach, thus facilitating complete Business-IT synchronization.

Difference in Systems

Beyond the obvious differences in approaches to methodology, it’s not just on a conceptual level that you see how ECC has evolved past R/3. Even at a systems level, consider that both A2A and B2B integration are now capable of being completed with the use of Enterprise Services (Web Services) rather than proprietary methods like BAPIs, iDOCs, etc. Also, with the arrival of ECC’s new functionality using Switch Framework and Enhancement Pack-based upgrades, it’s clear that the focus is now on providing solutions specific to customers’ unique business and IT needs, rather than offering everything under the sun.

What impact does ECC and SOA have on SAP consultants, managers, shareholders, and customers (all SAP users)?

This was the question that had brought Part 1 to a close, which was intended to implant a lingering thought in your minds along the lines of: “What does (or should) this mean to me ?“

It is plain to see that the onset of ECC and its improved functionalities described above are having a huge impact on the way we implement our projects. Frankly speaking, solutions are not (nor should they be) about bolting on function modules, IMG configurations, and traditional ABAP programs anymore. Nowadays, the most effective and optimized solutions that satisfy business and IT requirements come from really understanding first what those business and IT requirements are by getting entrenched in the processes at hand, and then relating those back to capabilities of the tools provided by ECC. But in order to do this, understanding ECC’s full spectrum of capabilities and its supporting tools is key.

You may be thinking to yourself, “this suggests that business problems weren’t being addressed before ECC – is this really the case?

Below are 2 major reasons in support of why examining the business problems are more relevant today (with ECC) than before (with R/3).

The Right Tool for the Job

One explanation as to why ECC provides more flexibility in terms of addressing unique requirements is that, there are multiple tools to perform a similar function. For example, you have more than 4 different tools for creating/modifying sales order screen -- WD ABAP, WD JAVA, BSP, Visual Composer, HTMLB, Adobe Forms etc. They will more or less all provide a screen to create a sales order on ECC backend, but it’s really a matter of knowing which tool would be the most appropriate to use, based on the requirement at hand. Therefore, the technical developer would need to know and choose the right option that would be suitable for that scenario. The same idea would apply to other components of the solution as well (PI, MDM, etc).

The Right Role for the Job

Another reason is related to the point above, but has more to do with the type of role that is required for such a task as described above. This task would be a good assignment and suitable for someone in a ‘Solutions or Enterprise Architect’ role, who could assess various tools and an provide an overall IT approach in the context of the business requirements. Additionally, a person in this role would need to have a good understanding of the functional (business process-related) issues, while also showing strengths in several different technical areas, mostly in newer technologies such as NetWeaver. People with a strong techno-functional skill-set often transition quite smoothly to EAs.

What I’m pointing to here is that the architect role is needed more than ever now that ECC is the system in place for at least another 3-4 years, and this role will continue to be more important as SAP technologies progressively improve. In the R/3 world, the concept or term of a solution architect was practically irrelevant and non-existent. But this is definitely not the case anymore. Obviously what this means for technical developers is a need to up-skill in order to be familiar with tools like NWDS and the ABAP workbench-based development tools of ECC. But probably more importantly, what it means to functional consultants is a major need to increase their overall awareness about these architectural changes that have happened from R/3 to ECC and to be able to integrate this knowledge into their process- and functionality-centric work. Jon Reed had summarized this nicely in his blog, “How is the SAP Functional Skill Set Changing?”

Leveraging ECC with SOA-based Solutions

Taking a step back from the changes that impact us as SAP practitioners, there are two 2 key benefits of SOA which can be encapsulated in two words: Adaptibility & Reusability.

The key driver for the change from R/3 to ECC is actually adaptability (meaning the ease with which solutions can accommodate unforeseen changes in an unpredicted context), and in order for that to happen, the focus should be more strategic / long-term in addition to looking at the immediate requirements at hand. All this should be able to happen in conjunction with any day-to-day & major actions that are being taken by decision-makers.

And by the way, SAP has gone to great lengths to incorporate industry standards in their ECC-based solutions in order to ensure interoperability in a heterogeneous environment. So one should think twice before going with a solution component that does not utilize these recommended industry standard-based components. This final point is what architects and key stakeholders must bear in mind in order to incorporate this strategic vision in their solution approach.


Out with the Old and In with the New: From R/3 to ECC & SOA (Part 3: CHALLENGES)

While the changes from R/3 to ECC were addressed in Part 1 and the impact of those changes were then examined in Part 2, this 3rd and final blog takes a new direction which is focused on the challenges around this change. Specifically, it reflects on why there has been a lack of understanding about the capabilities of ECC, and how this has had a direct impact on the true realization of SOA as well as on fully leveraging the benefits brought about by these new capabilities. This unawareness is particularly important considering SAP’s clear direction that SOA is actually an integral part of ECC and Business Suite 7 architecture.

So let’s look at how and why, in many cases, people have not adjusted as well as hoped to the utilization of new architectural capabilities of ECC (while sticking to the ways of R/3), which can have repercussions in implementations because the returns that these platforms are capable of providing are not being fully realized.

Why the utilization of enterprise services on ECC has been a slow and not-so-smooth process for some...

Take a look at this article: SOA Remains a Mystery, Say SAP Users by Leo King (CIO.com)...in it you will notice that according to a recent study, many SAP users (in this case UK-based businesses) are still pretty much in the dark when it comes to either understanding SOA or having an implementation strategy around SOA. The example provided by this article is intended merely to point out the lack of SOA adoption that is occurring among the SAP user community -- and not just within UK, but within other regions as well.

Since ECC was officially released, there has been a general attitude among SAP users that would point to a not very widely supported or welcomed use of ECC’s SOA-enabling capabilities. Instead, there is somewhat of an apprehension when it comes to utilizing Enterprise Service-based functionalities within ECC, suggesting a difficulty to adapt to the many changes that have happened since the R/3 era.

Some common reactions to SOA (ECC’s enhanced capabilities) among SAP users who are not necessarily ‘onboard’ with these changes...

1. “I don’t have to know about SOA”

The main culprit for this unresponsive attitude in my opinion is a prevailing lack of awareness about what is “under the hood” of the newly upgraded platform (ECC),- whether we talk of functionality & capabilities, the range of components, or about enhancement packs, switch framework, and so on. It’s true that there is quite a bit to learn about all the advancements of ECC, however, it is not as overwhelming as it might seem, especially since SAP Community Network has provided so much learning material around ECC’s many capacities. If people really want to learn, they have vast amounts of information available to them within SCN alone.

2. “SOA is too involved & complicated”

Another reason for the slow adoption has to do with common misconceptions that exist in terms of new approaches that introduce SOA. For instance, the idea some people have that “SOA involves extensive development efforts and additional licensing” is actually unfounded. In fact, it’s just the opposite, since acquiring a license for ECC is all that it takes to access the components and tools which are capable of enabling SOA. And as far as development efforts are concerned, using a SOA-based solution approach can actually reduce implementation time dramatically (thanks to use out-of-box enterprise services and enhancement pack capabilities).

3. “SOA is not mature enough”

And here’s another general misconception: “Enterprise services are new and not tested”. While there are plenty of reasons that dispute this claim, a detailed explanation goes beyond this particular blog topic. There have definitely been enough success stories and evidence over the past couple of years which point to enterprise services being very capable of enabling appropriate, technically solid, and reliable solutions for customers over the years.

4. Uninformed statements from the SOA Nay-sayers

Another reason why ECC’s capabilities around SOA have not completely caught on is just plain skepticism and denial. Hearing things like, “Everything should be done by configurations” and “SOA is still a marketing hype” simply come across as uninformed statements, and would suggest that there is a big learning curve in store for the owners of these kinds of statements.


And finally, the lagging adoption of ECC is also due to folk’s prevailing mode of tactical thinking rather than long-term or strategic ways of thinking. The focus instead, tends to be on fast and cost-effective implementation (to the extent that the word “accelerated” sometimes frightens me when it comes to describing project methodologies/approaches). It’s like saying “Let’s just go with the quick-fix approach instead of tackling the bigger issues”.

In other words, people choose to launch into a 4 to 6-month rapid-implementation without pausing for a minute to think about how that implementation might (or might not!) be able to support new product launches down the line, or perhaps how it would impact the merger that the company might be going through in couple of years. I’m not trying to undermine the need at times for cost-effective and short lifecycle implementations, but rather am pointing out the need to keep the larger, more long-term direction of an organization in sight.

Some ‘work-arounds’ with these above-mentioned challenges

The key here (especially in terms of the preceding example) is to involve strategic-thinking and enterprise architect-based roles from the very get-go (even before the implementation’s start), in order to keep a broader perspective in sight when making solution-driven decisions.

In my real-world experience educating about new approaches that move away from the ‘R/3 way’ of doing things to both practitioners and customers, there have been many times when it was better to avoid using the acronym “SOA” altogether. It’s as if a negative connotation has been attached to SOA (mainly due to the reasons listed above). Instead, the best approach is sometimes to bring the focus primarily on ‘Enterprise Services’ or ‘Web Services’ which people seem to be more receptive to, rather than referring directly to the term ‘SOA’. This whole idea was very eloquently explained in another blog called “SOA is Dead”.

However the education process unfolds (with or without the word ‘SOA’), it’s better to learn about these new approaches sooner rather than later, and by whatever means possible. Keep in mind that SOA is as much a part of ECC as the Business Suite is, so let’s wave goodbye to R/3 and welcome all that ECC and its counterpart SOA bring to the table.

It’s also worth pointing out that SAP is really ahead of its competitors in terms of service-enabling its core ERP platform. We should really leverage these benefits in the solutions we develop and provide to customers as much as possible.

Ranjan Baghel , an Associate SAP practice Director in Fujitsu, educates and advises SAP customers and practitioners about utilizing SAP's latest go-to strategies around ECC6 and its SOA underpinnings.



2009年3月1日星期日

SAP EAM设备维护系统应用及案例

前言

-摘自《SAP EAM设备维护系统应用及案例》一书

资产效率最大化和成本最低化是资产密集型企业的核心竞争力。几十年来,设备维护的管理理念不断推陈出新。早期的设备维护主要是事后的故障修理,后来发展到 强调事前保养的预防性维护,再进一步到企业资产生命周期管理。与此同时,各种先进的管理模式也逐步建立成熟,如从发挥每个员工能动性角度出发的全员设备维 护(TPM)模式,以及以行为分析为核心,建立从功能、故障、原因、后果和措施等完整流程制度的可靠性为中心(RCM)管理模式等等。在人类社会的发展历史进程中,理念和技术总是相辅相成互相推动的。上世纪中期开始的信息技术革命,同样也带来了设备维护领域的技术更新。企业资产管理EAMEnterprise Asset Management)系统越来越成为资产密集型企业必备的管理工具之一,也是TPMRCM等管理模式的技术基石。

EAM这 个名字几年前就开始在国内传播,可能读者已经不觉得陌生了。它是一套先进的管理信息系统,以资产设备和备品备件为基本管理对象,覆盖资产生命周期(选型、 安装、计划、维护、修复、分析和报废)上的各个环节,提供预防性维护及故障维护等各种维护模式,以维护任务的计划、提交、审批、执行和分析为业务主线,辐 射集成了采购、库存、项目、成本会计和人力资源等管理系统。按照著名研究机构Gartner Group的调查,EAM系统可以在不明显增加维修费用下,通过现代信息技术降低停机时间并增加生产产量。EAM可以给企业带来的效益有:提高有效工作时间10%~20%; 降低库存成本10%~25%; 减少设备停机时间 10%~20%;增加设备使用效率20%~30%;延长设备生命周期10%左右;使库存准确率达到95%以上。

作为全球第一大和年收入78亿欧元的应用软件公司,SAP的软件产品在中国市场已得到了广泛应用。但是一提到SAP,可能大多数人马上联系到的是ERP(企业资源计划),而不会想到EAM。事实上,国内外许多石化、钢铁和电力等资产密集型企业都已经运行了SAPEAM。造成这种“陌生”感觉的原因可能是许多项目都是以企业级应用平台方式实施的,EAM的光芒或多或少被火热的ERP所掩盖了。所以SAP ERP系统中所包含的思想和流程在中国已经被广大企业所熟悉和应用,但是EAM却没有被充分认知。希望本书一定程度上能够让更多的人士从EAM角度了解、熟悉并借鉴SAP在该领域的理念和经验。

和其他一些EAM系统相比较来说,SAP系统的最大特点在于集成性和拓展性。SAPEAM系统和ERP等系统是完全实时集成的,对于企业来说,这意味着再也不会陷入信息孤岛的陷阱中去。信息孤岛一直是信息化建设实务中努力避免和消除的现象,因为它给企业带来了大量的集成成本,阻碍了企业内部信息的流通和共享,无法形成企业级的业务透明度。另外,专从EAM核心的设备维护领域来看,SAP产品也具有一贯的严谨细致风格,表现为丰富的管理功能和严密的“德国工程师”式设计逻辑。相信国内外的应用软件领域从业人士,对这一点感受颇深。

国内目前应用EAM的策略分为两类:企业级和部门级。“企业级”指企业具有一个整体信息化规划,将EAMERPCRM(客户关系管理)和SCM(供应链管理)等统一纳入企业的管理信息平台,采用“统一平台、统一规划、集中管理、分步实施”的信息化战略。“部门级”指的是由企业设备管理部门牵头单独进行EAM系 统的评估选型和实施,和其他系统(如财务系统、电子采购系统等)构成多条纵向体系,不进行企业级信息平台的规划,而是通过点对点的方式进行系统集成。虽然 当下许多行业内的公司还是处于采用部门级策略的状态,但是从信息技术发展的历史来看,从部门级到企业的发展是一条必由之路。大部分EAM系统都只能够支持部门级型策略,而SAPEAM系统可以让企业自由选择是企业级还是部门级。

行业内宣讲EAM理论和好处的文章已经太多,本书的基本原则是关注实务和执行,而非纯粹理论探讨。书中以产品模块为脉络,基于多年以来的实施应用经验,按照实施顾问的思路阐述各构件模块。在EAM系统实施应用过程当中,实施顾问充当的角色并不是系统操作培训员,而是方案架构师。她/他 们的主要职责在于对公司的整体组织模式、业务流程和系统现状作出分析,并设计出合理优化的解决方案。所以本书的开篇是从组织结构设计开始,而非直接介绍功 能模块。也因此在随后章节的阐述过程中,尽量地设计出一些业务场景,以便读者能够更好地结合理论和实际。书中最后还介绍了多个国际公司的EAM案例,以供读者参考。

本书共分为十二章,以下对各章节内容作出一个简介:

  • 第一章 组织结构EAM系统是一套管理系统,将会给企业的管理制度和业务流程带来很大的提升。“管理改进,组织先行”这条管理原则在EAM系统内一样适用。因此组织结构被作为了开篇之章,其中介绍了财务、维护、采购和库存业务范围的组织结构模型,以及分析比较了不同业务范围的集中和分散两种模式。

  • 第二章 主数据管理。主数据管理包含通常所说的设备台帐管理,并将范围扩大到EAM相关的各种静态数据管理。本章介绍了功能位置、设备和物料(包含备件和材料等)的管理方法,并且以业务场景的方式介绍了电站、车辆和建筑等类资产的应用示范。

  • 第三章 预防性维护计划。本章介绍了预防性维护的体系、策略、流程、计划逻辑和监控手段。预防性维护能够有效防止非计划停机,减少生产损失。EAM中的预防性维护分为基于时间、基于绩效和基于条件三种形式,根据预先定义的任务清单和计划文件定期产生维护任务,并对维护任务进行监控。通过EAM和生产自动控制等系统的集成接口,企业还可以对资产设备的即时状态作出迅速反应。作为补充,第十二章的案例部分介绍了一个EAMPI系统的集成实例。

  • 第四章 维护工单管理EAM系 统中,工单管理分为通知单和维护订单两部分。二者可以结合应用,也拥有单独的业务流程。通知单用于报告资产设备的故障或异常情况等信息,请求维护部门执行 维修任务,并且记录已经执行的作业。维护通知能够用来处理完整的简单维修业务,也可作为初级的计划和执行管理工具,记载维护历史。维护订单是详细计划维护 任务和监控执行的工具,作为维护任务指令,下达给维修部门开展相应的维护活动。维护订单可以详尽的计划工作步骤、资源(人力、机器、备件材料、工具)和成 本,控制执行过程以及预算,并且详细报告执行过程和结算实际成本。

  • 第五章 工作清场管理。所有技术对象的维护维修任务,只能在实施了安全保证措施后才可以进行,包括:挂牌上锁,消防和辐射防护等。工作清场管理(Work Clearance Management)可以用来控制和监控安全措施,从而确保维护员工有一个安全的工作环境,保证企业遵从环境保护条例。应用工作清场管理,能够实现安全制度流程标准化,建立审批和安全追踪制度,从而有效满足法律和公司内部的安全标准。

  • 第六章 项目维修EAM中 的项目管理系统提供了项目管理能力,可以规划复杂的维修项目结构,进行全方位的进度控制,以及从下到上的成本计划和从上到下的预算分配和监控,实时管理项 目资金。本章详细介绍了维修项目的立项、定义、计划、执行和分析过程,从进度、成本、物流等角度全面阐述了维修项目的管理方式。

  • 第七章 采购管理。 采购管理能够建立一套采购管理的平台,实现对供应商全面统一的管理,并支持设备、备件、材料和服务等采购业务流程的管理。采购系统和工单系统是无缝集成在 一起的。在一个集团多组织模式的企业里面,集中采购是一个重要的管理主题,本章中对此也进行了概括性阐述。鉴于采购管理已经发展到了供应商关系管理(SRM)的阶段,最后一节还对SRM进行了介绍。

  • 第八章 库存管理。维修备件的库存管理水平是决定企业经营管理费用高低的一个关键。EAM系统的库存管理系统支持在集中和分散模式下,对于各种备件和材料等物料,从数量、价值、状态等各个角度,进行各类库存事务管理,并提供大量丰富的查询、统计和分析功能。

  • 第九章 维护成本会计在 企业内部,维护成本的发生和流转是每天都在进行的。维护成本会计的目的在于建立计划、控制和分析维护成本的机制,提供透明详细的经营信息。本章通过业务情 景分析了维护成本分析的管理目的,对成本管理模型(由成本要素、作业类型、成本对象和成本流四部分组成)进行了介绍,并对第四章中介绍的工单成本进行了补 充。

  • 第十章 查询统计和分析EAM系统利用其集成性和全面性的特点,给企业管理人员提供了一个完整统一的数据查询和分析平台。本章中重点介绍了EAM系统内统计分析的“信息系统”技术,列举了维修、采购和库存方面的关键绩效指标,并对部分指标进行了定义说明。同时,本章还详细介绍了用户可以采用的分析手段,如ABC分析、对比分析和预警机制等。

  • 第十一章 实用技术。本章介绍了移动技术、中间件集成技术和工作流技术在EAM系统内的应用:移动技术突破了台式电脑的局限,大大拓展了EAM系统运用的地域范围;集成技术已经从以前的点对点方式,发展到了集成总线的时代;工作流技术提供了开发配置工具以及预配置的模板。

  • 第十二章 案例。本章介绍了三个国际SAP EAM应用的实例:1)国际化学公司的世界级维护战略,读者从中可以看到EAM系统和企业战略的结合模式;2)电厂的EAMPI系统集成案例,对于需要做到基于状态型预防维护的企业来说,这是一个很好的例证;3)核电公司内的工作清场管理。

SAP”已经超出了一个系统的概念,而代表了一套体系和模式。对于来自于机械、化工、电力、石油、交通等资产密集型企业设备部门的读者,将可以从本书中看到如何运用信息技术提高资产设备的工作效率和水平。对于企业管理者来说,将可以借鉴EAM系统在组织结构和业务流程方面的管理理念,并运用到管理实务中去。对于EAM系统的实施团队来说,包含各种模式和案例的本书将会是一份实施参考资料。对于有志于了解或者进入信息化领域(特别是SAP领域)的专业人士和大中专院校师生来说,本书希望能够提供一个开始。

-摘自《SAP EAM设备维护系统应用及案例》一书

92年上海机床厂引进R/2系统起,SAP就开始了和中国企业紧密合作推进信息化的历程,至今算来已有10多年。期间,SAP已经帮助许多的中国企业消除了信息孤岛,建立了企业级的应用管理平台,提高了决策支持、财务、设备维护和供应链等诸多领域的管理水平。SAP的产品亦已深入人心,图书馆里面也有很多的书籍从ERP的角度阐述SAP系统的功能和理念。但是一直以来,我们就希望能够有一本书从EAM,即资产管理和维护,的角度来讲解介绍SAP的产品,并且又能够结合实际的中国市场应用经验,而不仅仅是功能介绍。这次汪昌任的书可以说满足了多年的夙愿,他邀请我作序,我也就欣然为之。

在 市场经济下的资产密集型行业,可靠运行和利润最大化是两大相辅相成又有一定对立的追求目标。比如在电力企业,其生产运营的目标是在可靠运行的基础上产生最 大利润。在石油石化的上游行业,一次油井故障可能带来数百万美元的损失。资产在这类企业里是重点的管理对象,实现既可靠运行又能够增加利润的有效方式是加 强资产运行管理并对成本实行精细化管理。将资产的有效管理与企业的生产、成本和盈利能力结合为一体,在运营管理过程中,及时发现管理中的问题,发掘改善管 理的潜力,从而实现企业资产回报最大化的目标,已经成为国内外资产密集型公司进一步深化企业IT应用的一个热门话题。

因为工作的关系,我们经常和各类型企业进行信息化交流,在与用户的交往过程中感到EAMERP都不是什么新名词,但人们对它们之间的关系普遍存在着误区,甚至将它们对立了起来。很多企业都已经实施了设备维护系统(可能还不到EAM的 层次),但往往是部门级的应用系统,无法将资产管理有效地纳入到企业一体化的维护、物流和资金流的管理当中去,最终影响了信息化的投资回报。可以想象,如 果没有有效的备件供应链管理,设备维护如何能够有效执行?没有建立设备维护的成本模型,如何能够在预防型维护和故障型维护之间取舍平衡?因此企业在考虑应 用EAM的同时,应该用长远的眼光考虑到和ERP等系统之间的关系,提高到企业级管理平台的高度。从理念上来说,就是要考虑到信息化建设中的全面性集成性原则。即使在设备管理的范围内,也应该考虑这两个原则。我很高兴地看到本书中,作者就是以全面和集成为出发点来阐述资产业务管理方方面面的。

这本书的思路和作者本人的行事风格非常相似,思维活跃、全局感强。书中以全球最具权威性的SAP EAM系统为原型,并没有采用常见的一些教条式和纯理论性的说教,而是采用了一些业务情景实例并融合了作者的亲身经历,这和作者具有长期咨询顾问的背景和丰富的实践经验是分不开的。该书的出版,是企业管理人员、IT人员、关键用户和业务人员值得借鉴的一本手册。我们期待着作者今后有更多精彩的书籍,可以将企业的单项业务管理课题,从整个企业的业务管理角度阐述它们,解析它们,并把它们的理念和流程管理结合到企业的IT应用中去,使IT应用为企业创造更大的价值。

SAP中国高级副总裁/上海分公司总经理 张雪峰


SAP EAM的设备管理及示范

-摘自《SAP EAM设备维护系统应用及案例》一书

SAP 技术对象管理简介

维护对象的管理在EAM系统内称之为技术对象管理。技术对象管理建立起企业建筑、设施和设备的结构化体系和系统档案,可以简化维护流程和技术资料的维护工作量。技术对象主数据是资产管理的基础,并决定了维修维护的对象范围。

技术对象可以分为功能位置和设备两大类。功 能位置一般指设备安装的位置,以“功能”为原则对技术系统进行划分。例如,我们可以将某石油运输管道线视为将石油从起点运输到终点的顶级功能位置,而将某 泵站视为实现该环节泵送的子级功能位置。设备则是从物理角度划分的单个技术对象,如某规格型号钢铸泵。设备可以在功能位置上安装、拆卸和修理,并可存放在 库存里面。功能位置和设备都可以是维护的对象。

在应用实践中,两种划分方式可以结合使用, 通过安装和拆卸关系实现关联。如将某规格型号钢铸泵从某泵站的功能位置上拆卸下来,修复后重新安装上去。在指派维护任务执行时,可以同时指定二者为维护对 象,功能位置为执行的场所,设备为执行的具体对象。这种双重指定和互联的关系可以支持管理人员作出如下分析:是安装在该功能位置的设备经常发生问题?还是该设备无论安装在哪儿都经常出问题。

技术对象主数据以编码为惟一标识,将信息分门别类进行结构化存放。作为整个EAM系 统的基础,主数据管理满足了各个不同部门的需求。计划部门需要管理计量读数仪器、状态以及故障和维修历史等,以此作为计划编制的依据。维护执行部门需要能 够查询到文档资料、技术图纸、历史维护记录和故障解决方法。财务部门需要层层管理到资产价值和维护成本。技术部门需要管理对象的技术参数和原厂商等信息。 根据多方面需求,系统将相关信息分为不同的视图进行信息划分。

ABC公司示范

ABC公司是一家大型多元化公司,施敏、唐真和林强分别是设备维护部门的经理、计划员和维修工程师。设备维护部门负责公司所有设施及设备的管理维护,主要包括数十条不同产品的生产线、一个燃气电站、多栋厂房和办公建筑、车队、办公设备和物流设备等。

1 单独设备管理

ABC公司,维修计划员唐真负责汽车的管理和维修工作,EAM系统的实施使她能够更有效地管理每个对象。当汽车用EAM进行管理后,大量的数据记录在系统中,可用于各种评估和管理。一些对于维修计划员来说十分重要的问题,都可以很轻松地在系统中找到答案。

一辆汽车应具有的各项数据是什么(例如,车型、保修期、牌照、车辆、底盘编号、高度、宽度或者引擎参数)

过去一年中曾有过什么样的维修(例如,散热器维修或事故维修)?是否每一辆车都有维修的历史记录?

某台车辆的维修成本是多少?

每个制造商型号汽车的平均消耗成本是多少?

除了对汽车进行技术性管理外,唐真也同时使用EAM来管理车队的运行流程。系统支持管理其日常业务,如制定车辆和员工的相关资源计划,处理原料采购和燃料补给等。使用EAM中的各相关模块,她可以在一个系统内就了解到ABC公司的基础组织结构,以及业务或技术方面的信息。在以下的每个情况中,EAM 均能促使维修计划员优化工作流程,并提高成本费用的透明度。

2 复杂技术系统

EAM同样可以构建大型的技术系统。如化工公司使用了EAM ,能够按照本行业特点,清晰地掌握极为复杂的生产设备情况。在电力行业,架构技术系统的工具能够给企业带来显著的效果。以下在ABC公司的燃气发电站例子,标准化的商品软件根据电厂资产生命周期管理特点而进行了量身裁剪。如图2-12所示,EAM系统根据电厂的标准设计来构建整个电厂的技术对象结构,标准的关键码包含了从上到下的完整组织定义,从而提供了一个清晰的沟通平台。

2-12 电厂标准关键码架构

同时正如所期望的那样,EAM系统也可以绕开通用的关键码结构而使用公司自己的习惯描述。ABC公司便运用了这个功能,有效地综合了标准结构和常用描述,这样使得用户使用系统时能够仍然看到原来熟悉的名称。

林强作为ABC的维修工程师,偏爱于系统的灵活性。他不但可以了解特定的技术对象情况,还可以选定技术对象的安装地点。这种功能使得林强可以从不同角度出发作出多种多样的评估,例如:

在某个的安装地点,生产哪一个产品时马达的停工率最低?

安装在技术系统中关键位置的马达已经运行了多久?

仓库中是否有足够符合要求、可用来替换的备用马达?

EAM可以定义多种关键码结构,对于同一技术系统,制定不同的标签。ABC 的化学工程师和生产控制工程师各自能够从自己的角度,从EAM中获得各自熟悉的视图,有效开展各自的工作。结合电力行业解决方案(针对电力行业需求而开发的解决方案)EAM系统还可以提供更多的管理功能。

3 序列号管理

ABC 公司需要管理大量的电脑。当在系统内录入供应商送来的电脑时,系统生成一系列的序列号,这样为每个单独的对象设立了识别标志。例如,假设新购置12A型和3B型电脑,且都已经先后送抵公司。EAM系 统将每一台电脑单独管理,并自动记录大量相关的重要数据,例如:该台电脑的成本、购置时间、硬盘存储空间、处理器速度。一旦电脑被配置好并送到使用者手中 时,下列数据也被添加到了主数据记录上:电脑上安装了什么软件?该电脑将被谁使用?目前该电脑在哪个岗位,哪个办公室,哪栋楼里?

这意味着 ABC公司可以为每一台电脑建立使用历史记录,提供维护技术人员关心的信息。

内存的安装频率是多少?目前的内存空间有多少?

显卡是否更换?

该电脑是否有病毒?如果有,什么部分受到感染而且需要重装?

该电脑在办公室之间的移动频率是怎样?是否曾在移动过程中受到损坏?

该电脑最后一次维修发生在什么时候?因为什么维修?

电脑上所安装的软件可以在ABC 公司的库存系统中进行管理。该公司需要从软件厂商取得一定数量的软件使用许可证。每一次的软件安装都是视为“向成本中心发货”。这样使得ABC 公司能够控制安装的次数,同时让有关技术人员可以了解并控制电脑上所安装的软件。图2-13 ABC公司序列号对象管理流程。

2-13 设备的库存管理

4 不动产管理

维护计划员唐真需要管理ABC众多的建筑物,如办公楼和厂房。许多建筑物的设备必须定期检查,例如供热系统、消防门、灭火器和电梯等。 EAM能够有效满足此类需求,提供强大的功能有效满足如下的管理需求。

如何降低维护成本?

如何在维护过程中,有效保持建筑物的使用价值?

怎样有效的计划和执行建筑物的检查和测量?

某维护项目的目标成本估计为多少?例如,供热系统的大检修,或者该建筑的改造。

唐真可以在任何时候获得历史上类似项目的有关数据(如日期和成本等),从而参考制定出新的计划。EAM 能向她提供大量的统计分析信息,使得她可以更好地制定出中长期计划。

另外,ABC公司计划明年将出租公寓和新建房屋,进入房地产经营领域。那么,公司就可以启用和EAM系统紧密集成的房地产管理系统来有效地管理该业务。

ABC公司在 EAM中将建筑物定义为功能位置,其结构如图2-14所示。建筑物中的各个单独物资设备,例如,电梯的液压马达、消防门和高压断路器,均作为单独的设备管理,并指定安装场所(功能位置)。同时启用了分类系统,使得维护计划员能更轻易查找信息,例如,找到特定型号的加热器等。

2-14 建筑物结构

5 分类

当觉得很难描述出行业内经常要用到的一些物资设备的所有特点时,可以使用EAM中的分类系统来描述每个物资设备的所有特征。

ABC公司对水泵的管理例子便充分说明了使用分类系统的好处。该公司的所有水泵都作为单台设备进行,并且记录关键的数据,如制造商、型号、采购价格、成本中心以及安装地点。维护工程师林强使用了分类系统,将泵的技术特性设置为一系列的特征,如图2-15所示。

2-15 泵的分类示例

每个水泵的性能都进行了详细记录,记录下来的信息都直接链接到主数据,如图2-16所示。

2-16 技术对象的个别属性

自从EAM使得用户可以准确地描述每个物资设备后, 林强的同事们便可以在系统内及时地对下列问题作出处理。

ABC公司中在用的部分电脑已经过时了。相关的负责人必须找出在某个建筑物中的某个办公室里内存小于100兆的电脑,这些电脑需要被更换掉。

在技术设备系统方面,一辆叉车需要更换发动机。维护计划员唐真需要找出可以在7米高的斜坡上载重3.8吨的发动机。

用同样的方法,林强已经定义在可能的功能位置上安装备件的需求。

ABC公司某技术系统上的一台发动机出现了问题, 唐真需要找到至少马力为20千瓦的发动机用以替换。

ABC公司的市场部门中有一台打印机需要更换。用于更换的打印机必须是至少每分钟可以打印6页纸的彩色激光打印机。

使用分类系统,可以作出非常准确的分析报告。

ABC公司中有多少XYZ工厂制造的21寸显示屏,使用期少于2年,但在过去6个月中被报告有屏幕闪烁或其他缺陷的?

某地点安装的水泵中,有多少在过去三个月内发生了故障,这些水泵具有什么样的特征?

公司的促销宣传大巴在过去一年中外出活动过几次?

借助分类系统,EAM系统均可以实事求是地回答以上所有这些问题。

6 外部系统集成

施敏和唐真作为ABC公司的设备维护经理和维护计划员,会见了电力提供商Eco-Power公司的员工,大家交流了彼此在应用GIS(地理识别系统)方面的知识。

在能源行业,如电力行业,员工需要在任何时候都能获得地理位置信息和技术数据。EAM 同样可以支持典型的能源提供商如Eco-Power电厂的工作流程。例如,假设Eco-Power电厂的电缆在道路建设过程中被破坏,则电缆抢救中心需要创建被损电缆的故障报告,而在此之前,抢救中心的员工必须先确切知道被损电缆所在的位置。

类似于这样的工作要求均能在EAM系统的集成中得到满足。一旦将两个系统进行了集成整合,则GIS 将从EAM 直接获取技术数据。如果Eco-Power的员工要找到特定物资设备的所处方位,则可以选择直接从EAM系统中获取以下地理位置和技术数据。无论是创立故障报告还是修改主数据,一个系统中所修改的内容会马上在另外一个系统得到相应的更新。


SAP EAM的预防性维护模式

预防性维护较故障后修复的维护模式更可以优 化资产,降低非计划的停机时间,减少故障影响范围。在危险性行业,法律规定企业必须采取预防措施保证生产及人员的安全。预防性维护可使资产利用率最大化, 延长资产生命,有效地降低资产折损成本,同时减少停产损失。另一方面,预防性维护会带来额外的人力成本、材料成本和管理成本,成本额和预防性维护频率成正 比。如图3-1所示,企业和组织需要平衡各种经济和非经济因素,比较预防性维护成本和故障后修复成本,判断特定的技术对象是采取预防性维护还是故障后维护。

3-1 成本平衡

如图3-2所示,EAM系统中,预防性维护的业务流程可以分为5大步骤。

(1) 创建任务清单:标准化维护过程的工序,作为资源计划及调度的基础。

(2) 创建预防计划:创建维修策略,为技术对象建立维护计划。

(3) 调度计划任务:定期激活预防计划,产生维护通知单或者工单,自动产生资源需求计划。

(4) 执行维护任务:维护任务进入维护工程师工作清单,执行维护任务。

(5) 关闭维护任务:统计资源消耗、实际时间和其他数据,关闭该阶段的维护任务。

3-2 预防性维护流程

1 任务清单

任务清单指某一特定维护任务(包括检查、维护和计划维修)所 需重复执行的工序序列,其概念类似于制造业的生产工艺路线。任务清单可以应用于维修订单,也可以应用于维护计划。根据所维护技术对象的不同,任务清单可以 分为:设备类任务清单、功能位置类任务清单和通用类任务清单。预先维护任务清单可以标准化公司的维护作业,避免在每次发出维修维护工单时都录入工序指令, 提高效率并减少失误。

任务清单以主数据的方式保存。在EAM系统中,任务清单的编码是有特殊性的。任务清单按照其相似程度被分为不同的组,具体某个任务清单在组内有一个流水号。也就是每一任务清单编号由一个组号加流水号(“计数器”)两部分组成。分组的主要用途在于简化维护的工作量,增强系统应用效率。如泵类拥有多种不同情况下的维护任务清单,可以设置如下。

组号:PUMP-MNT,“泵类维护工序组”

计数器1 “检查工序”

计数器2 “更换齿轮工序”

计数器3 “马达维护工序”

2 计划文件

EAM系统中,维护计划管理以维护计划为管理对象,提供从创建到监控的业务流程管理。维护计划管理和下述模块全面集成:①客户服务模块,服务订单、服务通知单;②物料管理模块,服务采购、服务输入表;③质量管理模块,检验指标、检验批;④销售和分销模块,框架协议。流程如图3-4所示。

3-4 预防计划的管理流程

如上图3-4所示,维护计划在系统内的管理流程分为4个步骤。

(1) 创建计划文件,定义预防性维护的周期、跨度、触发条件、负责人、技术对象、任务清单等计划参数,类似于日常业务管理中的维护制度。

(2) 触发计划。根据设定的时间或者状态触发计划,产生维护工单,指明需要对某技术对象执行检查和修复任务的范围,以及日期安排。

(3) 分派任务。维护任务交由相关负责人员负责执行。

(4) 监控计划。计划人员可以随时监控计划的触发以及执行状态,处理各种异常事务,进行可能的计划调整。

如图3-5所示,在EAM系统中,维护计划可以分为三种形式。

(1) 基于时间:每隔一定的时段就进行预防维护,例如6个月。

(2) 基于绩效:当技术对象的运行达到一定水平时进行预防维护。如行程达到10000公里或者起降次数达到5000次。绩效数据来自于技术对象的计数器。

(3) 基于条件:当某状态超出或者进入某一数值范围时进行预防维护。如温度超过75摄氏度或者厚度低于15毫米。状态数据来自于技术对象的测量点。

3-5 预防计划的三种形式

在基于时间和基于绩效的维护计划类型中,其应用逻辑都是根据系统内定义的周期进行触发的。“循环周期(cycle)”是计划内基本的一个概念,代表了维护任务的重复频率,用来确定下一次维护任务的具体日期。有时候,周期是单一的,有时是包含一系列复杂的组合。为了细化维护计划的管理,EAM系统将维护计划划分为三种不同的类型。

单一周期型:只有一个循环周期。如汽车一年进行一次检修;复印机的累计复印张数每达到1万张就进行检修。

策略周期型:按照同一周期单位、不同的周期长度进行不同的维护任务。如水泵维护计划包括,一月进行一次的外观检查(铁锈,不透水性)12个月进行一次的变速箱的磨损检查。

多计数点型:具有多个循环周期,且每个周期具有不同的单位。如飞机的维护任务依据飞行小时数(周期单位为“小时”)、起降次数(周期单位为“次”)和飞行公里数(周期单位为“公里”),制订不同的维护任务。

不同形式和类型的维护计划组合关系如图3-6所示。

3-6 预防计划的三种类型

3 计划运行

维护计划建立之后,EAM系统首先需要启动该计划,初次计算技术对象的维护计划日期。随后定期地运行计划,不断地重新计算计划日期,并且将快要到期的计划日期转换为维护工单。在启动及定期运行的过程中,EAM系统提供计划引擎,根据“输入”的数据及参数,计算得出计划日期和维护工单作为“输出”。计划引擎的输入参数和输出结果如图3-8所示。

3-8 计划引擎

初次运行:当创建好维护计划后,必须进行第一次计划运行,称之为“启动”。在运行启动程序之前,需要指定维护计划编号和起始参数。基于时间维护计划的起始参数为开始日期,基于绩效维护计划的起始参数为测量点/计数器的初始读数,多计数点维护计划的起始参数为当前日期和计数点的当前读数。系统随后运行计划引擎,计算出第一次的计划日期。

重新启动:当后续过程中发现初次运行存在错误的时候,可以重新启动维护计划,所有已计算出来的计划日期被删除,然后重新进行计算。但是,已经转换成维护工单的不受影响。

定期运行:初次运行后,系统需要根据技术对象运行状态和维护任务的实际执行情况,周而复始地运行计划逻辑滚动计算计划日期。可以设定频率自动运行(如设定一个每日的后台作业),也可以手动随时运行。常见的模式是后台自动运行,因为这时系统可以批量地运行多份维护计划。

手动调整:为提供更大的灵活性。对于系统自动计算得出的维护计划日期,用户可以直接更改日期,或者在图形界面上采用“拖/拉”的方式形象化地调整日期。

4 结果评估及监控

4.1 结果评估

计划结果在系统内有着两种表现方式:图形式和表格式。在图形式中,以维护工序为纵向,日期为横向,以点状图形象地表示出计划结果,不同的图标和颜色代表计划的不同状态,如图3-15所示。通过图形方式,用户可以方便地以“拖拉”方式模拟计划变化,以及对工作中心的能力负荷影响。表格方式下,则直接列出计划日期和创建日期清单。

3-15 计划结果评估

4.2 成本估算

利用存在的数据,系统可以估算一段时间内维护计划的成本,从而可以预见维护计划的成本,提供决策支持能力。成本估算遵循如下步骤。

(1) 汇总指定期间内所有有效的计划日期,不包括已经失效或者删除的计划日期。

(2) 为每一计划日期模拟创建维护订单/服务订单,选择相应的任务清单。

(3) 系统计算所有维护订单或服务订单的成本,并且进行加总。每一订单的成本包含备件材料费、内部人工费、内部机器费、外部服务费四部分,其量和价的来源如表3-6所示。间接费用并不包含在模拟的范围之内。

3-6 成本估算

备件/材料费

物料(数量×单价)

任务清单内指定的材料数量

物料主数据的库存价格

内部人工费

人工(工时×单价)

任务清单工序内的人工作业类型

成本会计的人工作业类型单价

内部机器费

机器(机时×单价)

任务清单工序内的机器作业类型

成本会计的机器作业类型单价

外包服务费

服务(数量×单价)

任务清单外包工序的要求数量

服务合同或者采购信息记录的价格条件

5 基于条件的维护模式

在基于条件的维护计划模式中,往往需要将EAM系统和外部的自动控制系统(如,PCS系统或者SCADA系统)集成起来。当外部自动控制系统读取到技术对象的某个测量点的数据超过系统定义的范围后,会将相应的读数以及代码通过接口自动传送到EAM系统。EAM系统中会生成计量凭证记录测量点的值,并自动判断是否超出了预定义的范围,是则自动创建维护通知以启动维修流程。触发的判断也可以在EAM外部的自动控制系统中进行。通过预定义的工作流,维护通知可以以各种方式主动通知相关的计划和维护人员。

如某公司欲利用基于条件的计划来自动触发升降机的维修。其解决方案如下。

(1) 通过SCADA系统来自动监控升降机的状态,判断突发事件。

(2) 通过EAM系统的接口中间件,将SCADA系统和EAM系统集成起来,形成数据双向传递的通道。

(3) 某个马达发生故障时,SCADA系统会捕捉到信息并形成事件代码,数据通过接口转换成EAM系统需要的格式,生成故障报告。

(4) 通过自定义的工作流,将故障报告主动通知负责人员。

(5) 负责人员开始计划安排马达的维修。

SAP EAM的维修工单管理(上)

-摘自《SAP EAM设备维护系统应用及案例》一书

1 整体业务流程

工单管理的业务起始于预防性维护计划,或者技术对象的故障异常报告。EAM系统中,工单管理分为通知单和维护订单两部分。二者可以结合应用,也拥有单独的业务流程。

通知单用于报告技术对象的故障或异常情况等信息,请求维护部门执行维修任务,并且记录已经执行的作业。维护通知单能够用来处理完整的简单维修业务,作为初级的计划和执行管理工具,记载维护历史。通知单的业务流程分为5步:①故障和异常报告;②请求维护;③任务计划;④活动报告;⑤完成关闭。

维护订单是详细计划维护任务和监控执行的工具,作为执行维护任务的指令,下达给维修部门进行相应的维护活动。维护订单可以详尽地计划工作步骤、资源(人力、机器、备件材料、工具)和成本,控制执行过程以及预算,并且详细报告执行过程和结算实际成本。维护订单的主体业务流程包括5步:①订单创建;②详细计划;③订单调度;④订单执行;⑤确认关闭。如果企业存在整体外包或者部分外包业务,维护订单还可以集成触发外部服务采购流程。维护通知单和维护订单的整体业务流程如图4-1所示。

4-1 维修工单业务流程总览

企业可以根据实际管理需求,弹性地配置系统,设计各种情景模式下的业务流程。以下为三种常见的模式。

(1) 事后报告型业务流程。对于小故障,维修人员现场即时进行了维修,未发生材料费用。此类业务的关键在于事后需要报告故障及活动,建立维护历史,作为可靠性分析的数据基础。系统可以设置出活动报告型的通知单,提供尽可能需要多的字段来详尽记录维护信息。

(2) 损坏/紧 急型业务流程。当资产出现故障不能满足生产需求的时候,需要维护部门快速反应尽快恢复正常生产。此类业务的关键是反应速度。系统管理员可在系统内配置简单 快速的集故障通知和维护请求为一体的通知单。当用户录入故障报告后,系统立即创建一张紧急订单,即刻安排维修人员执行维修,任务完成后再进行详细的活动报 告和用料报告。

(3) 矫 正型业务流程。常见的业务是异常性维修或者预防性维护。此时资产不会影响生产的正常运行,从而流程规范、细致管理和提高管理水平是关键业务需求。系统管理 员可在系统内配置完整的通知单和工单处理流程。通知单用于故障报告或者维护请求,并记录技术对象维护前后的技术状态。工单用于详细的计划和监控,实现从创 建、计划、调度、执行到结算关闭的完整流程。

SAP EAM的维修工单管理(中)

-摘自《SAP EAM设备维护系统应用及案例》一书

2 维护通知单

2.1 通知单类型

常见的维护通知单有三种类型。

故障报告。当 维护对象出现某种不正常情况时,利用故障报告来描述这种不正常情况,同时可以提出维护请求。故障报告可以是事后报告。如点检员发现缺陷并立即进行了修复 后,可以用缺陷报告来记录出现了什么缺陷、什么原因造成的、是怎样被修复的。这时维护通知还起到一种完成确认的作用。

维护请求。不涉及故障,向维护部门请求行动/任务,如清洁和设备刷漆。

行动报告。用于描述已完成的工作,记载没有预先计划的维护活动。

维护通知还可以用于其他方面。如当需要增加一个新的资产,或对现有的资产进行改造时,可以使用维护申请向有关部门提出请求。

EAM系统中需要设置通知类型,采用2位数的代码惟一标识。通知单类型可以作为查询、报表和统计分析的关键字。针对不同的通知单类型,还可以设置系统参数,满足不同的管理需求,变化出不同的业务流程。例如:

通知单编码。决定编码的范围,以及产生方式是自动分配还是手动分配。

通知的录入界面。EAM系统内设计了尽可能多的录入字段,并将这些字段细分为20个不同的信息块。系统管理员可以对系统进行配置,从20个 块以及块所包含的字段中选择出需要部分进行“积木”组合,设计出不同的数据录入界面。如在设备损坏的情况下需要快速录入故障以触发后续流程,同时故障报告 人员还可能不是一个专职系统用户。系统管理员可以给故障报告设计一个简单快速的数据录入界面,同时为维护部门的通知处理用户设计一个全面详尽的界面,以便 于后续再丰富内容。

后续维护订单类型。如可以确定是产生内部维护订单、维护服务订单(客户)还是设备翻修订单。

涉及方。包括客户、联系人、供应商、用户、组织机构、部门和岗位等。

目录选择。控制可选择的代码目录,包括任务目录、活动目录、零件目录、故障目录和故障原因目录。

状态控制。决定该类型通知单将采取的状态控制体系。设立多少个状态,状态的前后联系如何,处于每个状态时可以执行什么业务。如某企业设立了建立、删除、冻结、待审、一批、二批、三批、下达、完成、重开9个状态。状态之间存在着一定的依赖关系,如二批必须在一批完成之后,完成必须在下达之后等,处于删除状态时不可下达等。

2.2 通知单结构

EAM系统中对通知单采用结构化的管理方式,如图4-2所示,主要包括下列信息。

4-2 维修通知单结构

一般性描述。维护技术对象、概括描述、发生位置、时间、报告/申请人、所属组织等。

通知项目行。可以包含多行,分别对应不同的故障点,具体数据则包括发生位置、故障/异常描述、技术参数、可能故障原因。输入故障/异常描述和可能故障原因时,可以直接输入文字描述,也可以选择代码目录中的故障和原因代码输入。

需要执行的任务。报告人或者通知处理人员可以初步计划需要执行的任务,如:30分钟内联系当事人、1天内派遣人员维修等。

已执行活动报告。事后确认的已执行的活动,其和任务的区别在于一个事后,一个事前。

2.3 代码目录

在 维护通知的生命周期管理中,需要经常对问题或需求进行描述:出了什么故障?可能是什么问题?需要执行什么任务?需要什么材料备件?已经执行了什么活动?最 直接的方式是输入长短文本来分别描述。另外一种方式就是采用目录技术,为每个可能重复出现的描述形成代码,以树状方式组织起来。该种方式能够提高业务效 率,同时为设备可靠性分析提供了可能的数据基础。

EAM的目录分为5种。

任务目录

活动目录

零件目录

故障目录

故障原因目录

每一种类的目录再分为两个层次进行管理。第一层为代码组:如图4-3中故障类的目录可以分为“1000 一般故障”、“7000 泵类故障”等代码组;第二层为代码:如图4-3中的1000(“一般故障”)组下可以分为“010 腐蚀”,“020 玻璃破损”,“030 松动”等;7000(“泵类故障”)组下可以分为“010 壳体裂缝”,“020 线缆老化”和“030 引擎杂音”等故障代码。

4-3 代码目录

2.4 解决方案库

很多时候故障报告时只能报告问题,却不明确原因所在,从而无法计划维护任务。EAM系统提供解决方案库来协助管理人员进行决策。解决方案库内保存各种症状以及关联的解决方案,症状和解决方案之间是多对多的关系。用户可以根据确切或者模糊的搜索条件查询症状的可能原因以及相关的解决方法。


SAP EAM的维修工单管理(下)

-摘自《SAP EAM设备维护系统应用及案例》一书

3 维护订单

在工单管理流程中,维护订单扮演着重要的详细计划角色。维护订单可以详细的计划维护任务中的人、财、物等资源需求,并进行具体的时间排程,控制监督任务的执行过程,同时也是成本会计的核算单位。维护订单的业务流程可以分为5大步骤。企业在配置系统时,可以采用所有步骤,也可以根据需求选取部分环节设计不同的业务流程。

(1) 创建:以各种方式创建维护订单。

(2) 计划:计划维护的工序步骤,指定负责的人力资源或者机器资源,分配所需要的材料备件和仪器仪表等工具,并且计划订单成本。需要的话,还可以分派预算。

(3) 调度:根据计划需求对人力资源或者机器资源进行能力均衡,按照资源瓶颈进行调度。检查材料备件的可用性,如果短缺的话,必须运行物料需求计划安排供应。系统采用许可控制的方式满足某些预算或者法规的前提要求。随后,下达维护订单,打印订单或工票,交由维修人员执行。

(4) 执行:维修人员领取计划内或者计划外的材料和备件,执行维护任务。

(5) 确认关闭:当维护任务工序多、跨度长时,需要定期进行工票确认。全部任务完成后,可以对订单进行技术关闭和业务关闭:技术关闭表明维修任务已经完成,资源和物料需求被核销,订单不能再修改,但仍然可以记入成本(如延后到达的发票)。业务关闭后,订单不可以再接收成本。成本管理部门随后可以结算订单发生的料工费等维护成本。

维护订单管理和EAM系统中其他的部分是紧密结合在一起的,体现如下。

与库存管理集成:处理订单所需材料的计划和出入库业务。

与采购管理集成:处理订单所需备件或者外包服务的采购业务。

与项目管理集成:复杂的维护任务需要采用项目管理方式(如停机大修项目),订单由项目WBS派生而来。

与质量管理集成:可以详细记录检查的结果,管理质量检查中使用的计量器具。

与财务会计集成:使用集成化的财务会计功能,可以管理供应商和客户数据,并生成和检查发票。

与资产会计集成:与资产会计的集成,可以将订单产生的费用转入相应的资产账户中,同时,也使得可以从财务和维护两个角度来看待企业资产。

与成本会计集成:可以监督、分配和评价订单所产生的成本。

与人力资源管理集成:人力资源模块可以提供每个员工的资质和日历,从而订单的人力计划可以细致到员工级。

与外部系统的接口:如外部备件系统。

维护订单管理的细节功能阐述篇幅过长,再此不一一赘述,请参考《SAP EAM设备维护系统应用及案例》一书。


SAP EAM的工作安全管理简介及示范

-摘自《SAP EAM设备维护系统应用及案例》一书

5.3 工作清场管理简介

所有技术对象的维护维修任务,只能在实施了安全保证措施后才可以进行。这些安全保证措施包括:挂牌上锁、消防和辐射防护等。如美国职业健康安全协会OSHA 规定所有的动力设备均需上锁挂牌后才能进行维护及维修。根据相关资料,每年因为不遵守以上规定至少导致120人丧生,6000万人以上受到伤害。大部分有关未遵守上锁挂牌程序的意外伤害都属于下面5种原因:未把机器或设备停下来;未确切切断动力源;未排除残余的能量;意外地把已关闭的设备开启;在重新启动之前未将工作现场确实清理。

工作清场管理(work clearance management)可以用来控制和监控安全措施,从而确保维护员工有一个安全的工作环境,遵从环境保护条例,保证技术系统的可用性。应用工作清场管理,能够确保标准化安全制度流程、审批、安全追踪和满足法律及公司内部的安全标准。在电力、化工和石油天然气等行业,都需要进行工作清场管理。

维护订单模块和工作清场管理是松散耦合在一起的,二者流程可以集成关联,也可以断开运行,其整体运行关系如图5-1所 示。当维护任务只是记录一些简单的工作,不需计划和收集成本时,可以只应用工作清场管理模块管理一些安全措施。对于每一张维护订单,都可以指定是否要执行 各种工作清场管理:上锁挂牌、辐射防护、消防和有害物资防护等。当指定了任何一个选项后,维护订单在执行完日期、成本和资源等计划后,需要通过工作清场管 理模块的业务流程,才可以下达给执行部门。工作清场管理模块也必须等待维护订单执行完毕后,才可以解除安全措施。

5-1 维修订单和工作清场的耦合关系

以不同类型的安全措施为对象,工作清场管理可以分为不同的安全应用。上锁挂牌(lockout/tagout)是基本的应用,通用于各个行业。在特定行业存在着其他的应用,如辐射防护,消防措施等。根据是否需要采用行业相关的应用,EAM系统提供两种模式的系统架构:只包含上锁挂牌的标准模式和包含行业应用的增强模式。标准模式为两层架构,增强模式为三层架构。每个层次有着相互关联的不同管理对象。

上锁挂牌指在设备设施维修、保养和正常运行 时,关闭电源开关,关闭或者隔离动力源,将设备上锁并加以警示挂牌,控制意外释放出一种或多种可能对员工造成伤害的能量,使员工的工作场所、设备设施处于 安全状态。上锁挂牌的对象如电气线路及开关、液压系统及阀、供水系统及阀、供气系统及阀和重力系统等。图5-4为某系统的上锁操作示意图。

5-4 上锁挂牌

如前所述,操作单是实现上锁挂牌管理的主要 工具。工作清场操作单详细描述了上锁挂牌的处理对象、程序及方式。操作单包含有多行,每一行指定了需要上锁挂牌的设备、功能位置、尚未纳入系统管理的其他 技术对象等,包含上锁挂牌的条件、解除条件、安全类型、打印格式和挂牌编号等信息。用户可以在系统内建立操作单的模板,简化操作。系统可以打印出操作清 单、挂牌和测试牌等纸面文件,以供现场执行所用。

业务应用情景

在电力公司ABC 的维修工作规则中,存在着下述特点。

负责设备管理的员工常处于危险的工作环境中,他们容易接触到高危物质如高压电、高辐射和毒气等。

公司需要采取特殊措施保护员工健康,预防职业病的出现。

生产系统运转的同时要对设备进行维修。

同一个工作系统内的其他功能在任何情况下均不能受到干扰。

为了有效管理维修任务,ABC公司应用了EAM系统中的的工作清场管理模块。以下的流程情景展示了工作清场管理系统是如何在设备维修过程中发挥作用,从而确保安全措施顺利执行的。

(1) ABC公司的技术人员发现发电站给水系统中的一个水泵正在漏水,并在EAM系统内提交了一份故障报告。

(2) 维护计划员随即在EAM系统内创建了一张维护订单,其中说明在维修水泵的过程中需要采取上锁挂牌的安全措施。

(3) 由于还未计划和执行必须的安全措施,计划员目前还不能下达维护订单给维护部门。

(4) 在知道要采取上锁挂牌措施后,工作清场申请人在EAM系统内创建相应的工作清场应用单并分配给之前创建的维护订单。(工作清场应用单和操作单是作为工作清场管理的管理对象,用于控制执行安全措施的流程,如上锁挂牌)

(5) ABC公司的工作清场计划员在EAM系统内创建工作清场操作单,并将其分配到工作清场应用单上。这些操作单包含多行需要上锁挂牌的设备,或者要在上锁挂牌期间进行监控的设备部位。

(6) 安全管理工程师从EAM系统中打印出操作程序和挂牌,开始执行上锁挂牌了。列在文件上的执行对象(如正在漏水的水泵,用以替换的水泵或水环流中的电阀门等),根据要求被关上或者开启,分离或连接或者上锁,并用标牌一一标示。

(7) 现场上锁挂牌完成后,安全工程师在EAM系统内确认工作已经执行。

(8) 现在,ABC 的维护计划员在EAM系统内将维护订单下达给维护部门,工程技术人员便可以在安全的工作环境中开始维修水泵了。

(9) 在工程技术人员完成维修工作后,维护计划员检查确认维修工作顺利完成。这时候不再需要上锁挂牌,标牌需要去掉,机器需要恢复正常运行。

(10) 工作清场计划员确认不再需要上牌挂锁后,便关闭工作清场应用单。安全工程师开始根据操作单去现场解除挂牌。

(11) 现场的挂牌解除后,安全工程师在EAM系统中进行确认,然后关闭操作单。


SAP EAM的项目管理(上)

-摘自《SAP EAM设备维护系统应用及案例》一书

为了保持整体设施和设备的全面稳定性,工厂定期需要全面停产大修。类似大修这样复杂的维护任务,具有时间跨度长、涉及部门广、资源投入多、管理结构复杂的特点,需要采用项目和维护工单结合的管理模式。EAM中的项目管理系统提供了项目管理能力,可以规划复杂的项目结构,进行从下到上的成本计划和从上到下的预算分配和监控,监控项目资金。项目的WBS元素下,可以分配给多张维修订单。维修订单可以进行本单的成本计划和控制,计划所需资源,并进行任务排程。项目和订单的关系如图6-1所示。

项 目管理系统是一套集成的解决方案,旨在搭建企业统一集成的项目管理平台,建立整合透明的项目信息体制,增加企业对维修项目的监控管理力度。通过项目管理系 统,企业能够设计项目管理的组织结构和业务流程模板,推进项目管理的标准化和规范化,为决策分析提供强有力的信息支持。项目管理系统能够实现在资本性支出(为维护对象增添新功能)及成本性支出(恢复维护对象原有功能)项目整个生命周期上,全过程的投资、计划、物流和进度管理,优化从投资预算、估算、概算、预算、预算控制调整、成本归集、付款、结算到决算的财务资金流,真正体现“财务和项目一体化”的现代项目管理思想。

系统按照工作分解结构(WBS)和作业网络(activity network)进 行管理,对成本、预算、资源、进度进行计划、执行和关闭的管理。在项目生命周期上,集成采购管理、库存管理、维修订单管理和财务管理模块。采购业务、维修 业务能够围绕层层分解的项目展开,实现自动化的维修采购计划和材料预留,自动收集核算成本和结算或转资,提供完整全面可穿透追溯的项目统计分析报表。

6-1 项目管理和维修订单

1 投资和立项管理

1.1 投资

投资管理允许用户在整个企业范围内对维修投资进行总盘计划, 并且对每一项具体的投资进行实时控制和分析。

项目管理系统中可以维护投资大纲(investment program),它和项目以及维修订单一起构成了大型维修任务管理的“金字塔”三层体系。投资大纲是一种树状结构,结点上可以链接到项目或者内部定单,并对项目或内部定单进行预算控制。对投资大纲结构进行层次划分的规则有按照组织结构(如按照总公司、公司、二三级单位层层划分)和预算控制明细程度(如细分到专业)

在 集团企业内,投资需求经常是自下而上呈报。项目管理系统中,可以通过创建投资申请来进行投资需求上报,在投资申请中列明投资原因、投资类型、负责人等基本 信息,同时输入计划的投资成本、时间。投资的计划成本会层层往上汇总,各层管理人员可以在系统内查询投资所有下属单位的总投资申请,对投资计划进行分析、 平衡和审批,调整下级的投资请求。

根据投资计 划成本以及企业的总体规划,可以制定出投资预算。投资预算的传递方向是从上到下,在顶层维护总额后,按照结构层层分解,实现“总盘控制”,避免预算调整受 人为控制。经过批准的预算即为确定的投资计划,可以分配给相关的项目。如果项目尚未立项,则可以依据投资申请创建项目定义。下发的预算只是让项目负责部门 明确该项目的上限,真正使用预算要经过释放之后。如某些项目需要做出详细设计之后才可以开始使用预算和开工建设。

在 项目实施过程中,费用可能超出总体的预算,从而使项目无法继续进行。这时,项目负责人会要求增加预算。企业预算管理部门可以进行两种选择,一是从尚未使用 的预算中拨一部分给该项目,另一个是将其他项目多出的预算转拨给该项目。项目预算调整不仅是增加或拨转,还包括减少项目预算、回收项目预算和将年度预算结 转到下一年度。预算管理部门可以根据年度投资的预算和实际执行情况,不断进行调整,以保证所有项目的顺利进行。而多余的预算也可以及时地被发现,并指导预 算管理部门回收这些预算,或结转到下一年度。

投资计划的管理过程中存在着大量的审批过程。EAM的工作流可以进行审批流程的控制,工作流可以在EAM系统内闭环运行,也可以纳入办公自动化OA系统中以统一工作方式。

1.2 项目立项

可以更改投资请求的状态而作为立项申请,通过工作流、OA办公自动化系统或其他系统上报给公司管理部门,组织进行评审。可研立项审批流程中的各种可行性研究报告、立项报告等可以由EAM的文档管理系统进行集中管理,并和立项申请一一对应。评审不通过的项目需要返回修改。审批通过的请求,由相关管理人员在系统中释放,自动创建项目定义,并分配项目初始预算(类似于估算)。项目负责部门根据自己的要求,可以进一步分解项目的工作细分结构——WBS,同时指定相应的项目负责人等。对于突发性的项目,可以直接创建项目定义,经过特别审批流程后直接分配预算。

如果多个大型的维修项目具有一定的相似性,可以在系统内创建标准项目模板。创建新的项目时,可以拷贝项目模板的内容,并做出特别部分的修改。这样可以缩短复杂结构项目的维护时间,加强标准化,提高效率。

1.3 项目设计

项目的设计过程常见的有初步设计和详细设计。项目设计阶段一般需要经过各种审批,如设计会审、会审批复等。审批流程可以通过工作流、OA办公自动化系统或其他系统完成。设计阶段的大量文档存放在EAM系统的文档管理模块中,利用远程调用技术,并得到全面、集中和统一的管理。项目设计的主要结果是项目结构、进度计划、资源需求和概预算。

2 项目结构

项目系统中,以WBS将一个项目进行结构化的组织分解,用网络勾勒出流程化的项目任务,以里程碑定义出重要的阶段或者事件。项目管理系统可以和外部的进度管理软件,如Microsoft ProjectP3等系统实现数据集成交互。项目的整体结构如图6-2所示。

6-2 项目结构

2.1 项目定义

项目定义是一个基本框架,包含了整个项目所需要的基本信息(例如:开始、结束日期,组织相关数据和计划参数),它包括了可以传递到WBS元素中的默认数值。

2.2 WBS

WBS是结构化的项目元素。它将项目分解为不同层次的更小的管理单元,从而得以自上而下和自下而上对之进行预算、计划和控制。WBS是一个成本对象,也是作业和里程碑分配的载体。WBS的可以按照按照项目阶段、功能、对象(组件)等进行分解。

WBS中包含的关键数据如下:①日期类,如基本日期、计划完成和开始日期、实际完成和开始日期;②预算类,如初始预算、更新预算、释放预算、可用性控制参数;③资金承诺类,如采购申请、采购订单;④成本/收入类,如计划成本、计划收入、实际成本、实际收入;⑤付款类,如付款计划、实际付款;⑥组织结构及地点类,如设备、功能位置、工厂等。

2.3 网络

网络是流程化的项目元素。它描述的是项目执行过程,代表了任务执行的逻辑顺序,用于项目进度安排,成本和资源安排,项目分析和控制工作。构成网络的关键元素是一个个的作业(activity)。作业具有以下特征:持续一定的时间;有明确的开始和结束;执行的过程不被中断(指如果有中断应定义多个分开的作业);执行需要一定的资源;引起成本。作业和作业之间通过定义先后关系(FSSSFFSF)形成一个作业网络。作业和网络都可以分配给WBS

网络与作业中包含如下关键数据:①内部作业类,如所需执行工作、日期、工作中心、工时需求、资格等;②外部作业类,如日期、采购组织、采购组、采购信息记录、供应商、所需服务和付款计划等;③成本作业类,日期、成本、作业等;④物料类,物料编码、数量、日期等。

2.4 里程碑

里程碑(milestones)是项目中有特殊重要性或者会触发某些事先定义功能的一类事件。一般来说它们显示了项目各阶段或各部门间的衔接点。在系统中里程碑可以分配给活动(activity)WBS元素。利用里程碑可以实现四种功能:①里程碑趋势分析;②实现价值分析(earned value analysis);③里程碑开具发票(billing);④触发预定义的业务事件,如创建网络、释放后续作业和触发工作流等。

2.5 项目团队

沿着WBS的脉络,可以分配来自人力资源系统的组织机构单元或者个人,从而方便地建立一个项目小组。通过项目成员和工作中心的挂钩,可以进一步在项目成员级别进行能力分配和评估。

2.6 项目分类

在项目管理 系统中除了可以为各个项目提供惟一的编码进行层次化管理外,还可以运用分类系统对项目进行分类管理。企业可以在分类系统中定义任意多的特征,管理系统标准 字段中所没有覆盖到的信息,用于各种参考和分析用途。另外,项目分类支持对项目的快速检索查询,提供汇总分析的基础。

SAP EAM的项目管理(中)

-摘自《SAP EAM设备维护系统应用及案例》一书

3 项目计划

3.1 进度计划

项目进度计划的基本工具是计划面板,如图6-3所示。在计划面板上用户可以选择WBS元 素,采用基于项目管理标准的网络排程技术,对项目进行向前或向后排程,计算出每一个作业以及项目的日期时间。基于网络中定义的作业逻辑顺序,向前排程根据 设定的开始日期顺向推算作业的日期和波动范围,向后排程则根据设定的结束日期逆向推算。一个项目中各作业的日期经过从下到上的汇总,可以计算出项目的日 期。排程的过程中将会考虑各种约束条件,项目中的预测日期和实际日期在实际项目执行中对计划也有影响。

6-3 项目计划面板

3.2 物料计划

项目设计阶 段产生维修项目所需设备和物料的物资清单,包括使用时机以及数量单位等。用户可以从系统主数据库中查找已存在的物料编码,或者申请新的物料编码。具备了编 码的物资清单可以批量导入到项目管理系统中,也可以从标准项目模板中拷贝调整。如果尚未具备编码,则在申请编码之前,可以采用在项目内只记录物资描述的过 渡性方案。因为项目管理系统和采购、库存系统的集成性,系统可以自动产生库存物料的用料预留,以及非库存物料的采购申请。

预留的用料日期和采购申请的到货日期是根据需求日期决定的。物资清单中的每一行都可以和项目的某一个作业挂钩,这样就可以保证了物料的需求日期和作业进度计划保持一致。

3.3 资源计划

网络的作业中定义了所需的内部和外部资源,结合进度计划的结果,系统可以自动计算出资源计划。在外部资源方面,可以得出对材料供应商和服务供应商的计划。在内部资源方面,可以得出所有相关的工作中心以及员工个人的能力需求,并可以进行能力负载分析。

通过劳动力计划功能,管理人员可以对维修项目所需的各种专业技术人员进行有效的计划和调度。如图6-4所示,系统用户可以从项目的角度或者工作中心的角度,快速察看员工的已分配时间、可用时间和负荷率,将员工分配给项目作业。

6-4 维修技术工程师调度

3.4 成本计划

项目管理系统通过项目成本的计划、收集和计划实际比较来达到控制成本的目的,体现了现代管理会计“事前计划、事中控制、事后分析”的管理原则。成本计划往往采取自下而上的方式,从最底层最细节的活动或WBS元素开始进行计划,层层汇总和修正,最终形成整个项目的成本计划。系统可以提供简易成本计划、手工WBS成本计划、网络成本计划和维修订单成本计划四种计划方式。

(1) 简易成本计划。通过一个预定义的、可配置的、基于HTML格式的界面提供用户一个成本计划的简易工具。一般用于项目的初期阶段,可用于报价或者估算。简易成本计划的关键是提供了预先设计一个成本模型,如泵站大修的成本模型,用户只需要提供相关的参数就可以自动计算出成本。

(2) 手工WBS成本计划。根据项目的WBS结果,手工编制项目计划。系统提供了三种精度的手工计划方法:①直接编制WBS层的总成本,并层层汇总或者层层分解至其他层次。②编制WBS的成本要素(如外部服务、内部人工、材料)构成成本,较第一种更为详细。③编制每一种资源的成本计划,通过计划数量和调用系统内的价格数据,得出最为详细的成本计划。

(3) 网络成本计划。如果启用了网络,则在项目网络的作业计划中,可以计算出内外资源的详细需求量和时间。基于和采购、库存、财务等模块实时无缝的集成,项目系统可以自动读取诸如报价、成本结构和费率等数据,自动进行项目成本计划。

(4) 维修订单成本计划。通过将维修订单分配给WBS,可以对维修订单进行成本计划,从而自动传递到项目中。

运用不同方法计算的成本,或者运用同种方法在不同设计下计算出的成本,可以保存为多个独立的版本,进行对比分析。

3.5 预算计划

成本计划某种意义上可视为预算请求,资金将以批复预算的形式分配下来。如图6-5所示,预算分配的方向和成本计划相反,它往往是自上而下的。如果预算(包括各种阶段的不同表现:概算、估算等)是在系统外进行设计的,那么在得到批复后,相关人员可以以输入或者上载的方式将项目的预算按照WBS结构输入到该项目中。

预算进入系 统后,可以根据实际情况对项目的预算进行批次下达,也可以根据情况对项目进行预算的调整。系统提供多版本管理功能,可保存不同版本的概算,如初步概算、批 复概算等,而真正起费用控制作用的预算只能有一个。预算下达后,对项目的成本控制具有约束作用,可以提供了主动的“预算可用性控制”功能。

系统还提供了各种工具:原始预算编制、预算更新、预算下达和预算结转。预算更新包括了预算增加、预算返还和预算划拨。预算下达功能使得我们可以分阶段部分地下达预算,以避免预算过早地耗尽。预算的结转是指可以将本年未使用完的项目预算结转到下一会计年度。

6-5 成本计划和预算的关系

SAP EAM的项目管理(下)

-摘自《SAP EAM设备维护系统应用及案例》一书

4 项目执行

4.1 物料采购

物资设备需求在形成物料清单进入项目系统后,因为和采购系统无缝集成,项目管理系统可以自动触发相应的采购申请,自动传达到采购部门,由采购部门执行采购流程。项目管理人员可以通过系统方便的查询到物资采购的状态 (如申请阶段、招投标阶段、已下单、已到货、已收到发票、已付款等),有利于进行项目全过程跟踪管理。

非 物资的服务采购,如设计、施工、监理等,可以由采购系统的服务采购模块支持。首先由采购部门创建服务主数据,不同的服务编码代表不同的服务。通过项目管理 系统,项目计划人员输入所需服务清单,系统自动在采购模块中生成服务采购申请。采购部门可以根据这些服务采购申请与相应的服务供应商进行洽谈,签订采购合 同。供应商履行完其服务后,相应的费用将直接计入项目成本。

项目物资可以分为两类:直送现场和库房存储。对于直送现场的物料,可以由现场相关授权人员依照有效单据录入系统,财务角度上不记入库存账户而直接记入项目成本。而进入库房存储的物料则先作为库存入库,项目领用时再记入项目成本。

纳入库存管理的物资从实物管理上又可以分为通用和项目专用件。通用件指项目共享库存,由管理人员根据项目需求(预留)进行平衡发放。专用件则限定为只为某项目使用,其他项目即使需求同样物资也不可挪用。库存管理系统通过设立“项目库存”的库存状态可以区分通用件和专用件。

4.2 进度确认

项目管理人 员根据最新的、可靠的数据在系统中输入项目执行的实际时间和进度情况。企业管理人员可以通过报表实时查询到工程的形象进度,并由此判断项目是否按计划运 行、是否有延迟的倾向、是否有足够的能力保证项目的继续执行,并采取必要的调整措施。用户可以对每个任务进行进度确认,从而得到完整的项目任务完成情况。 在计划面板的甘特图上,系统用不同颜色来形象表示任务的完成情况。用户也可以按照里程碑进行确认,确认项目的阶段性成果,较为简单和直观。

4.3 工时确认

和维修订单一样,项目的工时确认也可以运用跨模块的时间表CATS(cross application time sheet)来进行时间和成本的记录,如图6-6所示。输入的时间在正式传输到项目管理模块之前可以首先进行审批和下达,而后输入的时间将直接影响项目的实际工时和成本。CATS还提供完整的更改和取消功能。

6-6 跨模块的时间表

4.4 资金管理

项目管理系统将项目的成本和现金流作为两个不同的方面来管理的,成本受到预算的控制,按实际发生的成本或一定会在未来发生的成本(如采购合同)进行总额的控制。而资金则不同,即使项目预算没有超支,也并不意味着银行账户上有资金可以对外支付。

项 目管理系统提供了一个现金管理解决方案,可以计划和监督与项目有关的现金流量。该功能可以保证项目产生的收款活动以最可能早的时间发生,项目产生的付款以 最可能晚的时间发生。现金管理功能还可以预测未来发生的收付交易。现金管理功能使得应收和应付款账目上借方和贷方的变化处于严密的监控之中。现金管理还提 供了项目付款的历史记录。

同 时,系统可以提供汇总方式报表。即可以按照某种规则,将所有符合条件的项目呈现在同一张报表上。该报表具有一个重要作用,即手工管理情况下,一般都需要报 请款计划,这是因为没有集成项目管理和现金管理的工具可以帮助进行这方面的统计,而实施项目管理和现金管理集成的财务系统后,可以根据项目最新的进展情况 直接查询应该给下级企业下月所有项目的对外支付情况,改被动申请为主动下发。

4.5 结算

WBS作为下属维修订单的成本接收对象。订单结算时,贷记订单的实际成本,借记WBS成本。结算完毕后,订单的实际成本余额为零,增加WBS实际成本。

各个WBS也会被指定一个成本结算规则,成本结算规则里面定义了成本接收对象清单和各自的结算百分比。一般指定相应的成本中心做为项目费用的责任部门。项目管理系统自动收集在该项目中所发生的成本,期末运行结算程序自动将项目上发生的所有成本结转到相应的成本中心。

5 项目分析

5.1 完成成本分析

该功能对比分析实际成本、计划成本和预测成本。成本预测是在项目执行过程中不断计算和调整完成项目剩余部分预计将要发生的成本,往往和计划成本具有差异。如图6-7中,目前阶段实际发生的成本都低于预期的计划成本,但因为是进度滞后而非成本节省的影响,因此,预计在后来阶段的预测成本将会高出计划成本。

6-7 完成成本分析

5.2 里程碑趋势分析

里程碑趋势分析(MTAmilestone trend analysis)是一种简单明了分析项目进度的方法。项目各个里程碑的计划日期在不同的时间点上进行比较,得出趋势曲线。线条水平表示该里程碑保持不变,曲线向下表示计划提前,曲线向上表示计划延后。如图6-8中,最上也是第三个里程碑提前完成,第二个里程碑保持计划不变,而第一个里程碑有延误。

6-8 项目里程碑分析

5.3 进度分析

利用收入值分析技术(earned value analysis),系统可以进行成本和进度两方面的形象化分析。

完工率(POCpercent of completion)用百分比来显示项目的进度。系统总共提供了九种确定POC的方法:开始/结束规则;估计;里程碑技术;时间比例法;成本比例法;数量比例法;进展程度法;次级比例法(或相关比例法);用户出口(允许用户自定义规则的程序出口)。计划POC是某个时间点上应该完成的任务百分比。实际POC是在某一个点上实际的任务完工百分比。

基于POC值,系统进一步提供各种指标的分析,反映各种项目的状态。包括:ACWPBCWSBCWPSVCVEAC。各值的含义可用图6-9表示,最上的红色曲线代表目前的实际进度下的实际成本,中间的黑色曲线代表了计划的进度和成本,最下的蓝色曲线代表了按照目前进度的计划成本。

ACWP(actual cost of work performed)。反映在某一时间点上消耗的实际成本。

BCWS(budgeted cost of work scheduled)。反映按照初始计划,到现在应该花费多少成本。计算方式为总计划成本乘以计划POC

6-9 项目EVA分析

BCWP(budgeted cost of work performed)。反映按照目前的进度,应该花费多少成本。计算方式为总计划成本乘以实际POC

SV(schedule variance)。反映进度差异,是计划成本BCWS和实际成本BCWP的差值。可以告诉管理人员项目是快了还是慢了,差异多大。

CV(cost variance)。成本差异,等于ACWP减去BCWP。反映按照目前的进度,所花费的成本是否已经超出了预算。

EAC(estimated costs at completion)。反映按照目前的进度和成本,将来项目完成后,预估需要多少最终成本。

SAP EAM的主要分析指标

-摘自《SAP EAM设备维护系统应用及案例》一书

1 维修相关

1. 故障分析

以计划工厂、维护工厂、地点、功能位置、设备和组件为特征,分析故障以及形成的原因。具体指标包括:

故障总数

故障原因总数

活动总数

有代码的故障总数

有代码的故障原因总数

有代码的活动数目

2. 停机分析

通过该分析,可以统计停机次数,分析停机原因,形成设备可靠性分析的基础。停机分析的关键在于MTTR(mean time to repair,平均修复时间)MTBR(mean time between repair,平均无故障时间)两个基本指标。

有效停机次数。停机次数分为报告次数和实际次数,二者可能不一致。如在图10-2的情形3,报告了两次故障,因此,报告的停机次数为2次,但是,实际次数却只有1次。图10-2显示了三种不同业务情形下不同指标的更新结果。

10-2 设备停机次数的计算逻辑

MTTR = 所有修复时间总和 / 停机次数,单位为小时。在图10-3中,第一次故障时间为8小时,第二次为11小时,则MTTR = ( 8 + 11 ) / 2 = 9.5小时。

MTBR 为两次停机之间的平均时间,单位为小时。公式为:MTBR = (第二次故障日期 起始日期 第一次故障持续时间)/ 2。在图10-3中,MTBR =[(2004.07.26 – 2007.07.01)×24 – 8)]/ 2 = (600 – 8 ) / 2 = 296 小时。

10-3 MTBRMTTR的计算逻辑

相关的指标还有:总无故障时间、总修复时间。

3. 其他分析

除了以上故障和停机分析外,系统还提供了如表10-1所列的分析指标。

10-1 工单管理信息系统的其他分析指标

技术对象统计指标

统计功能位置、设备的汇总

信息

功能位置的总数

没有安装设备的功能位置总数

安装了单台设备的功能位置总数

安装了多台设备的功能位置总数

设备总数

设备采购价值

维护通知单统计指标

统计维护通知单的汇总信息

创建的维护通知单总数

完成的维护通知单总数

处理天数(从创建到完成)

维护订单统计指标

统计维护订单的汇总信息。

创建的维护订单总数

完成的维护订单总数

紧急维护订单总数(在维护订单内标明“立即执行”)

紧急订单比率(%)

经过计划的维修订单总数

经过计划的维修订单比率(%)

未经过计划的维修订单总数

成本分析

统计汇总的订单成本信息

订单计划成本总计

订单实际成本总计

订单实际收入总计

实际成本总计–内部作业(及比率)

实际成本总计–外部作业(及比率)

实际成本总计–自有物料(及比率)

实际成本总计–直购物料(及比率)

实际成本总计–服务(及比率)

实际成本总计–其他(及比率)

2 库存相关

库存信息系统的特征主要包括业务范围、工厂、库存地点、物料组、物料、批次、计划员,分析指标如表10-2所示。

10-2 库存管理信息系统的分析指标

存货

分析公司自有存货和寄售存货的数量、金额、达到零库存的次数以及期间平均数(期初值加上期末值再除以2)

自有库存量;寄售库存量;安全库存量;在收库存量

自有库存金额;在收库存金额

自有库存为零次数;寄售库存为零次数

平均自有库存量;平均寄售库存量

平均自有库存金额

领用

分析物料领用的频率、数量和金额。分为计划领用和非计划领用两类。计划领用的指标更新自根据预留的库存业务(如维修工单内的物料计划),非计划领用的指标更新自非预留发货的业务

总共领用次数;非计划领用次数

总领用量;非计划领用量

总领用金额;非计划领用金额

平均每次领用量;平均每次非计划领用量

平均每次领用金额;平均每次非计划领用金额

最后一次领用日期

收货

分析物料领用的频率、数量和金额,包括采购收货、转储收货等各种形式的业务

自有库存的收货次数;寄售库存的收货次数

自有库存的收货量;寄售库存的收货量

自有库存的收货金额

平均每次收货量;平均每次收货金额

最后一次收货日期

(续表)

发货

分析物料发货的频率、数量和金额,包括领用发货、转储发货、销售发货等各种形式的业务

自有库存的发货次数;寄售库存的发货次数

自有库存的发货量;寄售库存的发货量

自有库存的发货金额

平均每次发货量;平均每次发货金额

最后一次发货日期

库存覆盖天数

分析现有的库存可以满足多少天的使用。理论上,库存覆盖天数应等于补货提前期,小于表示可能缺货,大于则表示可能库存过多。计算公式:

库存量覆盖天数 = 现有库存/平均每天领用库存;平均每天领用库存 = 期间总领用库存/期间天数

库存变量值可以是数量和金额

自有库存量覆盖天数

寄售库存量覆盖天数

自有库存值覆盖天数

寄售库存值覆盖天数

库存周转率

分析库存的周转次数,数值越大表示库存资金周转越快,资本可以带来更大的利润。计算公式:

库存周转 = 总领用库存/ 平均库存;平均库存 = (期初库存 + 期末库存)/ 2

库存变量值可以是数量和金额

自有库存量周转率

寄售库存量周转率

总库存量周转率

自有库存值周转率

总库存值周转率

收发次数

统计收发的次数,此类指标可以反应库房的工作量

收发总次数

库存计划

提供MRP结果的数据分析,包括预期的收货、发货和需求等数据

预期库存量;预期收货量;预期发货量;预期需求量

ATP数量

预期库存值;预期收货值;预期发货值;预期需求值

3 采购相关

采购信息系统的主要特征包括采购组织,采购组,供应商国家,供应商,物料组,物料,分析指标如表10-3所列。

10-3 采购管理信息系统的分析指标

数量/价值

分析采购量和金额

采购订单量;要求到货量;实际收货量;开票数量;

采购订单金额;开票金额

频率

分析询价、报价、采购订单、合同和框架协议的总数目和总行数。该类指标反应了工作频率,可以作为工作量考核的部分依据

询价单总份数;询价单总行数

报价单总行数

采购订单份数;采购订单总行数;采购订单计划交货行数

合同份数;合同总行数

框架协议份数;框架协议总行数;框架协议计划交货行数

交货次数

交货偏差程度

反映采购业务中经常出现的实际交货量及日期与计划交货量及日期不一致的情况,此类指标用于分析偏差程度的大小

日期偏差分析按照设置的参数,统计5种不同程度的偏差。如提前了20天以上为第一级偏差,提前了1019天的为第二级偏差……

数量偏差统计交货数量上的差异,可以设置按照差异百分比设置5种不同程度的偏差。该数据仅当订单被标识已经完成后才被更新

系统最终统计各种不同类型、不同层次偏差的总次数

1级日期偏差;2级日期偏差;3级日期偏差;4级日期偏差;5级日期偏差

1级数量偏差;2级数量偏差;3级数量偏差;4级数量偏差;5级数量偏差

(续表)

交货时间

统计从发出订单到收到货物的交货时间总和及其平均值

总交货时间

加权平均交货时间(采购量为权数)

供应商评估

评估供应商在数量、时间和服务方面的表现

数量可靠性

日期可靠性

装运通知偏差度

提供服务质量

提供服务日期