用于实施 ERP 和其他企业应用程序的资源？
在开发类似 ERP 的软件或任何其他复杂的业务系统时，您会使用哪些资源来获取最佳实践？
我是开发商，不是会计师，不是采购员，不是经理。
我确实有工程方面的项目管理经验（非软件相关），并且在设计、采购、库存管理、销售、制造、质量控制、售后等业务流程方面有相当多的经验。
但我的问题是在开发商业软件时，您总是会遇到缺乏专业知识的领域，我相信充分了解流程以及其他人如何解决类似问题对于开发合格的软件绝对必要。
那么，是否有一些在线资源提供了一些关于人们如何在 ERP 系统等中解决和实施业务规则和流程的最佳实践或实践经验集合？
When developing an ERP-like software or any other complex business system, what resources do you go to for best practices?
I'm a developer, not an accountant, not a purchaser, not a manager.
I do have project management experience in engineering (non-software related) and I have a fair amount of experience on business processes in Design, Purchasing, Stock management, Sales, Manufacturing, Quality Control, After Sales, etc.
My issue though is that when developing business software you always end-up confronted to areas where you lack expertise and I believe that a good understanding of the processes and how others solved similar issues are absolutely essential for developing competent software.
So, are there any online resources with some best practices or collections of practical experiences on how people solve and implement business rules and processes in ERP systems and the like?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我假设您指的不是软件的最佳实践。 你说的是商业惯例，对吗？
你去哪里？ 这似乎是显而易见的，但你必须在某个地方找到领域专家。 无论您的公司规模如何，他们都应该在您的公司内部。 如果您不太了解该主题，并且您不太可能成为专家开发人员和 GAAP 专家，那么您需要找到了解该主题的资源。
我认为这是做出购买与构建决策的正确场所。 当有这么多可用的会计软件包可以为您提供帮助时，为什么要编写会计软件包呢？ 大多数决定需要编写自己的总账的人通常会通过引用“荒谬的”许可成本来证明其合理性，但他们无法准确估计设计、实施、测试和维护自己的系统的真实成本。 购买软件包意味着获得开发人员接触过的所有人员的精炼专业知识。 你认为他们也做得很好。
I'll assume that you don't mean best practices for software. You're talking about business practices, right?
Where do you go? It seems obvious, but you have to find domain experts somewhere. They should be inside your company if it's of any size. If you don't know the subject well, and it's unlikely that you'd be an expert developer AND a guru on GAAP, you need to find sources that do know.
I think this is the right place for buy versus build decisions. Why write an accounting package when there are so many available that do it for you? Most people who decide they need to write their own general ledger usually justify it by citing "ridiculous" licensing costs, but they fail to accurately estimate the true cost of designing, implementing, testing, and maintaining their own system. Buying a package means acquiring the distilled expertise of all the people those developers contacted. You assume that they did a good job of it, too.
为了了解“事情是如何运作的”，您首先必须查看客户的内部程序：采购程序就是很好的例子。 它们通常都有完整的记录，因为采购流程被认为是大多数公司潜在的问题根源（相反，会计程序通常记录得很差，因为它们依赖于官方和强制性规则）。
通过这些程序，您将发现公司使用的所有标准表格，谁做什么，什么必须保留或存档等。这将帮助您在与负责人会面之前了解流程。 请始终记住，您的应用程序应遵守这些程序，如果程序不存在，则应用程序实际上将成为程序：在这种情况下，您通常有机会 (1) 按照#duffymo 的建议进行购买或(2) 根据客户的要求和规格进行构建。 在最后一种情况下，我建议您从用户那里收集他们已经使用的不同文档，通常是一些 Word 模板 + 一些 Excel 表格，用于数据跟进。 它可能是灵感的主要来源，并可以帮助您制定明智的提案...
程序跟进和管理模块（附件、提案草案等）可能是开始使用“类 ERP”系统的好方法。
In order to understand 'how the things work', you'll first have to look at your client's internal procedures: procurement procedures are good examples. They are usually fully documented, as procurement process is considered a potential source of problems in most companies (On the opposite, accounting procedures are usually poorly documented because they rely on official and mandatory rules).
Through these procedures, you will discover all standard forms in use in the company, who does what, what has to be kept or archived, etc. This will help you understand the processes before meeting the persons in charge. Allways keep in mind that your application shall stick to these procedures and, if procedures do not exist, the app will de facto become the procedure: in this case, you will usually have the opportunity to (1) buy as proposed by #duffymo or (2) build following your clients requests and specs. In this last case, I'd advise you to collect from the users the different documents they already use, usually some Word templates + some Excel sheets for data follow-up. It could be a major source of inspiration and could help you to elaborate smart proposals...
A module for procedures follow-up and management (annexes, draft proposals, etc) could be a nice way to start with your 'ERP like' system.
APICS（运营管理协会）位于 www.apics.org。 （“I”代表库存，但范例发生了变化......）许多城市都有一个定期举行会议的地方分会。
There's APICS, the Association for Operations Management at www.apics.org. (The "I" stood for Inventory, but paradigms change ... ) Many cities have a local chapter with regular meetings.
您已经拥有比其他任何人都更了解公司业务流程的内部专家。 只需去与您的会计师、经理、采购员、主管和系统的普通用户交谈即可。 他们会告诉您他们需要 ERP 系统做什么。 然后，作为开发人员，您只需在此基础上添加一些小改进即可让每个人都满意。
You already have internal experts who know your company's business processes better than anybody else. Just go and talk to your accountants, managers, purchasers, supervisors and regular users of the system. They will tell you what they need an ERP system to do. Then you just add few little improvements on top of that as a developer and make everybody happy.