Excel/Access的替换或迁移策略

Question

有没有一种方法可以提供终端用户喜爱的Excel/Access开发的灵活性，同时灌输集中化的IT管理，以便数据和逻辑是安全的，备份，版本控制等。常见的选项是用C#/ASP.Net/Java/Python/Your Choice重写，但这会夺走用户的控制权。有没有更好的方法，你在你的网站上做什么？

有一个普遍的问题是，用户创建非常有用的Excel/Access迷你应用程序，而IT部门希望对其进行控制。用户喜欢Excel提供的灵活性，特别是在动态更改、绘图和数据导入/导出时。在Access中，我们有出色的QBE。缺点是，过了一段时间，出现了大量失控的电子表格/mdbs，它们是任务关键型的，具有许多不太了解的业务逻辑和脆弱的代码，支持它们是一种痛苦，特别是随着员工的离开。

这让IT部门陷入了尴尬的境地，他们想要支持这些应用程序，但对它们却知之甚少。这变得更加困难，因为它们通常在没有文档的情况下是不安全的。

Answer 1

您是否考虑过在部门级应用程序中使用SharePoint？许多专业开发人员会对使用Sharepoint进行“应用程序开发”的想法犹豫不决，但这确实是“超级用户”开始将其数据和工具放在托管框架中的一种很好的方式。

使用SharePoint，您可以管理站点的整体结构，然后在用户各自的部门中设置具有提升权限的用户。有一些很棒的第三方工具可以帮助您监视SharePoint站点中正在发生的事情。

无论如何，SharePoint都不是灵丹妙药，但对于许多需要跟上数据列表的多用户应用程序来说，它是非常棒的。

(下面的内容与我上面的答案并不相关，但你的问题确实切中要害，我想我应该分享一下我的类似经验和见解。)

我们公司在不久的将来也将经历类似的过程。我是站在“最终用户”这一边的，我对Kevin Ross said的很多东西都很有同情心。有时，Access和Excel是我完成工作的最好工具。

这里有一个例子:几年前，我被要求想出一个系统，为中国的供应商创建一个有3个月交付期的产品的采购订单。我们的ERP软件有几个采购功能，但都不能接近我们面临的复杂情况。几年后，在Excel (VLOOKUP是救命稻草)、Access (“这就是人们使用关系数据库的原因，太棒了！)和Excel (”让我们不要把事情搞得太复杂“)中经历了几次迭代之后，我仍然发现这些Micorosft Office应用程序是完成这项工作的最佳工具。

不使用这些工具来完成工作的成本是多少？

• 与我们的企业资源规划供应商签订合同，为此订购流程添加一个特殊功能:你在开玩笑吗？我们可能会花数万美元购买一个缺乏灵活性的整体式应用程序，但如果用户是可怕的experience...and，我们最终还是会回到Excel中去。
• 购买了专门为这个过程设计的第三方软件:我在现场看过一个软件演示，它能为我们的采购过程做我想要的事情。起价10万美元。也许我们可以花几千美元买到其他工具，但在这个价位上，我已经在自己的application.
• Try中模拟了它们的大部分功能，以便“手动”完成这项工作。我本质上是一个程序员，这意味着我很懒。如果坐在办公桌前花了整整一周的时间来制定采购订单(实际上确实花了这么长时间)，你可以打赌我会想出一个解决方案，这样我只需要几个小时(现在确实做到了)。也许在我之后的人会回到过去手工完成大部分工作，但我会使用工具箱中的工具来节省时间和压力。--

很难找到一个完美的应用程序，既能在用户端发挥最大的创造力，又能让it部门“管理”它。一旦你认为你已经找到了一件事的解决方案，你就会意识到它不会做其他的事情。我是否可以像以前在Access中那样，在此解决方案中编写可打印的报表？我是否可以编写复杂的Excel公式，将不同工作表中的多个数据源连接在一起(“您想让我了解什么?不，我以前从未听说过"SQuirreL查询”。VLOOKUP很好，谢谢！)？我可以通过电子邮件将结果发送给部门中的人吗?它可以像我在Excel和Access中那样自动从我们的后端数据库中提取数据吗?我可以编写自己的代码，VBA或其他代码，以使我的工作更容易吗？

最后，在你的情况下，我能给任何IT经理的最好的建议就是尊重你公司的其他员工。让他们知道他们的工作很重要(即使这只对他们和隔壁的人有用)。让他们知道你并不是想让他们的工作更难做。不要假设他们是在办公生产力软件中创建任务关键型应用程序的笨蛋；他们只是试图用手头的工具完成工作，而且通常是非常有能力和聪明的人。邀请他们和你一起探索不同的解决方案，而不是简单地移除他们工具箱中现有的工具，然后用他们不知道如何使用的工具取而代之。

归根结底，如果您的用户足够聪明，可以通过在Excel和Access中创建复杂的应用程序来搬起石头砸自己的脚，那么他们很可能足够聪明，学会使用适当的工具来完成相同的任务。投入时间和精力让他们参与到这个过程中来，最终你会得到一个对每个人都有效的解决方案。

Answer 2

如果我站在两边，我会找出问题的根本原因。为什么用户要制作他们自己的小应用程序？因为这太难了/太贵了/太耗时了/当他们通过“适当的”渠道时永远不会变得正确。

另一件事是，他们往往非常了解业务，所以尽管他们的编码可能不是很好，但他们对需要做什么的了解非常好。

那么我们能做些什么来解决这个问题呢？我个人认为他们应该是IT内部的一小群人，他们的工作(或他们的工作之一)是开发这些小型应用程序。他们应该与最终用户紧密合作，而不是被锁在IT的象牙塔中。

在我目前的角色中，我是非IT方面的，我有几个相当重要的应用程序需要开发，所以我要求安装visual studio并在SQL服务器上留出一些空间。我的请求被拒绝了。因此，我只是请求SQL服务器空间，再次请求被拒绝(每个请求需要大约一周的时间)，所以最终我被“卡住”在访问中。

现在，这些都是非常好的访问应用程序的版本控制，评论在(震惊！)以及所有其他好的事情，但在一天结束的时候，我试图以“正确”的方式做事情，最终被迫走上了访问的道路。所以，当我的应用程序试图扩大规模，而我引用的是很长时间的重写时，谁应该受到指责？

Answer 3

您可以尝试一种混合方法:允许您的用户使用Excel/Access自行开发自己的专用工具，但将任务关键型工具置于it控制之下。有一些策略可以帮助你做到这一点：

• 确保您的IT部门对VBA的态度坚定。不是"yeah-everybody-can-write-a-few-lines-of-basic“类型的知识，而是深入的培训，就像它是一门不太简单的编程语言一样。尽管“真正的程序员”会告诉你不是这样，但用VBA.
• 编写大型的、稳定的应用程序是可能的。如果您当前的数据在Access数据库中，请远离Access数据库并将其迁移到SQL Server。这使您可以执行集中式备份和管理，同时仍然允许高级用户灵活地将这些SQL Server表链接到他们的Access frontend.
• Commonly使用的业务逻辑应由您的IT部门控制。这可以通过VBA来完成，方法是创建一个由用户链接的访问库，或者使用任何.net语言，使用COM互操作。后者听起来比实际情况复杂得多，而且它将提高您的it部门的满意度，因为使用.net进行开发比使用VBA (可能的版本控制等)更有价值。