你决定建造。内部定制的企业软件解决方案似乎是解决技术难题的最佳方法。也许工程部要求您的软件请求由内部管理。或者你只是没读过第一部分或第二部分我们系列中的……；）
无论您是如何做到这一点的，无论您寻求解决什么样的技术挑战，构建的决策都会经常遇到实施、维护、维护和纯粹的专有技术方面的挑战。我们经常接到一个电话我们的服务当内部软件管理问题浮现时。凭借我多年与客户合作和构建软件的经验，我了解了企业在构建自己的解决方案时所面临的挑战，也了解了他们购买解决方案的优势。
如果你不确定你的构建是否走上了正确的道路，或者你不想避免那些表明事情可能会出错的迹象，那么这个博客适合你。请继续阅读前三个场景，根据我们的经验，自制构建不太可能成功。
1.“我们正在努力”的构建
对于某些组织来说，规划是构建软件解决方案的关键。您的IT团队似乎渴望并愿意开发一种工具，组织领导层也热衷于规划……但是，**板球**。
也许行政审批会放慢速度，或最终阻碍发展。或者，它的铁板一块的过程需要额外的实现规范，而您不了解这些规范，或者需要团队之间进行大量的来回工作才能实现这些规范。或者可能由一个特别委员会接管并将任务添加到组织的项目计划和开发周期中，但在委员会考虑如何向前推进时，几乎没有任何进展。
在每一种情况下，您的组织成员都只是在努力做好自己的工作。但在这个过程中，您的解决方案几乎看不到任何进展。在建筑最终开始的可能性很小的情况下，经过这么长时间后，您的需求和资源可能已经完全改变了。
2.“那不是我想要的”构建
对于其他组织来说，不完整的规划，而不是过度规划，会阻碍构建解决方案的进度。例如，您的营销团队要求提供一个软件解决方案，该解决方案可以每天无缝地提供销售数据报告，而您热切而敏捷的IT部门则可以提供。但当市场营销部意识到他们需要时间戳和销售数字配对时，它会发布一个修订版。当市场营销部门决定合并用户数据也会有帮助时，第三次修订也会进行。最终，不仅解决方案永远无法完全满足市场营销的要求，而且到了第10版，资源耗尽，组织曾经反应灵敏、灵活（现在可能很沮丧）的IT团队被迫退出项目。
3.“问吉米”的建造
最后，让我们考虑一个场景，您的软件解决方案正在运行并运行！但是，它是由常驻专家“吉米”建造的，他是你们工程团队的成员。该解决方案通过一台本地台式计算机运行——它可以正常工作，但很脆弱。Jimmy充满激情，视野开阔，符合组织需求。尽管拥有一个能够提供您所需的软件解决方案非常好，但一个小故障、一次软件更新或Jimmy的离线休假都可能导致其失败。更不用说Jimmy的solo解决方案带来的局限性了，如果您的组织寻求多用户系统，那么整个组织中的其他人都可以参与这些过程。
从博客系列的开头开始
建造出错了…那现在怎么办？
无论我是否描述了您当前的构建，或者您担心其中一个场景即将出现，现在都是充分评估您的选项的时候了。是需要改进，还是该拉起绳索了？如果你一直听到“我们就要开始了”，看看这到底有多久了。等待几个月甚至几个季度的实施并非不可能。但如果你已经等了好几年了，就像（不幸的）经常发生的情况一样，也许是时候放弃了，并寻找其他的选择，让你的解决方案成为现实。
如果您的解决方案已经到位，但很脆弱，或者您没有获得希望的可交付成果，请检查维护它所需的流程。确保您清楚当前的需求，并对您在实现解决方案中所扮演的角色负责。不完整的计划只会给你和它的关系带来更大的压力，减慢或完全结束这个过程。此外，如果需要任何更改，请了解工程师的灵活性和可用性。调整是否只发生在您无法访问的黑盒中？您在IT方面的项目负责人是否已经离开了公司，以及与本土平台相关的机构知识？如果是这样的话，请考虑进行一个关于开放性沟通的对话，或者讨论购买软件的选项，这些软件提供给你和你整个组织的透明度和一个机会来访问它所有的错综复杂。
最后，如果你知道你的构建被破坏了，那么考虑一下这个机会，点击重置按钮并在这个时候购买一个软件解决方案。明智地选择。寻找具有强大的面向服务体系结构的供应商，以便您能够积极参与软件解决方案的实现。找到一个致力于了解您当前内部状态的供应商，甚至愿意从失败的项目中学习，这只会改进您的新解决方案并使其受益。帮助团队内部成员挽回面子并知道他们到目前为止的辛勤工作也没有白费，这也不会有什么坏处。
在Minitab，我们在为客户实施软件方面取得了巨大成功，同时，我们也看到了无数组织自创的软件难题，因此我们有很多建议可以分享，关于构建或购买企业级软件解决方案的决策。我们知道，两个看似简单的选项之间的选择可能是找到答案、改进流程和保持业务正常运行之间的区别——也可能不是。因此，一定要花时间了解你的组织，了解你的需求，了解你的选择的全部范围，这样你就有最大的可能实现你的目标。
准备好了解更多吗？
